Henri,

<< So the DBISAM product line wil be no further developed when ElevateDB is
ready? >>

Not right away, but within the first year of ElevateDB's existence, DBISAM
will most likely be phased out of active development.  We'll have to see,
however, since DBISAM and ElevateDB will be two separate products that are
sold separately.  If the interest in DBISAM remains high in terms of sales,
then we'll continue with it.  However, we will encourage people to use
ElevateDB.

<< Wil there be a feature matrix between DBISAM and ElevateDB, so we can
easely see the differences? >>

There will be documentation on what has changed between the two, yes.  A
feature matrix is a little hard for a lot of the changes since they need
some explanation in more detail than a feature matrix can provide.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
> No, nothing like that.  Just a bunch of objects representing the
> engine, sessions, etc.

It was a rather ridiculous question, but one never knows!

Hasn't DBISAM always been fully object-oriented? In what way does
ElevateDB improve on this? Maybe a tiny real-word-DB coding example...?

Tim Young [Elevate Software] wrote:

> Ralf,
>
> << Do we get a 100% OO DB? I hope not >>
>
> Well, if you would like to skip the TDataSet stuff and go directly to
> the engine, you can do so very easily with ElevateDB and have a very
> fast and lean, 100% OO DB.   It's really pretty cool, and the coding
> is very simple.

Interesting... Can't wait for a beta to test that out.


-AJ Marknette

Dom,

<< Hasn't DBISAM always been fully object-oriented? >>

Yes, and no.  It is partially OO internally, but a lot of the objects simply
wrap a set of procedural routines in a way that mimics a lot of the BDE's
functionality.

<< In what way does ElevateDB improve on this? Maybe a tiny real-word-DB
coding example...?  >>

Here's an example of using the bare-bones calls to the engine to open a
table and navigate it, putting the second column value of each row into a
label's caption:

procedure TForm1.NavigateButtonClick(Sender: TObject);
var
  TempEngineManager: TEDBEngineManager;
  TempSessionManager: TEDBLocalSessionManager;
  TempDatabaseManager: TEDBDatabaseManager;
  TempCursor: TEDBCursor;
  TempCursorRow: TEDBCursorRow;
begin
  TempEngineManager:=TEDBEngineManager.Create;
  try
     with TempEngineManager do
        begin
        ConfigPath:='c:\testapp';
        Open;
        end;
     TempSessionManager:=TEDBLocalSessionManager.Create(TempEngineManager);
     TempEngineManager.AddSessionManager(TempSessionManager);
     try
        with TempSessionManager do
           begin
           Open(TempEngineManager.Environment.ComputerName+
                IntToStr(TempEngineManager.Environment.ProcessID),
                'MySession','My Session Description');
           try
              Login(SYS_ADMINUSER_NAME,SYS_ADMINUSER_PASSWORD);
              TempDatabaseManager:=TempSessionManager.OpenDatabase('Test');
              try
                 TempCursor:=TempDatabaseManager.OpenTable('TestTable');
                 try
                    with TempCursor do
                       begin
                       TempCursorRow:=CreateRow;
                       try
                          First;
                          while (not EOF) do
                             begin
                             Label1.Caption:=Values.Items[1].AsString;
                             Next;
                             end;
                       finally
                          TempCursorRow.Free;
                       end;
                       end;
                 finally
                    TempCursor.Free;
                 end;
              finally
                 CloseDatabase(TempDatabaseManager);
              end;
           finally
              Close;
           end;
           end;
     finally
        TempEngineManager.RemoveSessionManager(TempSessionManager);
        TempSessionManager.Free;
     end;
  finally
     TempEngineManager.Free;
  end;
end;

Of course, all of the engine, session, and database set-up would only occur
once in the entire application. If you wanted to use a remote session, you
would just use the TEDBRemoteSessionManager instead and populate the IP
address, etc. before opening it.

In DBISAM, there would a whole bunch of record buffer allocation (PChars),
etc. taking place and it is a lot messier, especially when you get into
dealing with BLOBs, SQL, etc.  With ElevateDB, going directly to the engine
is not only an option, is it encouraged if you need the maximum amount of
performance and don't want to use the TDataSet architecture.  However,
you'll need the source code because, at least initially, we won't be
documenting the internals.

--
Tim Young
Elevate Software
www.elevatesoft.com

AJ,

<< Interesting... Can't wait for a beta to test that out. >>

Check out my example that I posted for Dom.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> AJ,
>
> << Interesting... Can't wait for a beta to test that out. >>
>
> Check out my example that I posted for Dom.

Looks nice. Can't wait

-AJ Marknette

I use Rubicon from Tamarack Associations with DBISAM.

Any ideas if they are going to support ElevateDB or will the search
function in ElevateDB be upgraded to match that provided by Rubicon?

KK Aw

Tim

> Also, triggers, procedures, and functions are now SQL-based with the option
> of using native code (DLLs for Win32, and assemblies when the .NET version
> is ready) for functions only.

I hope you don't skip the current way of "procedures". Will this be kept?

Arnd

Tim Young [Elevate Software] wrote:
> initially, we won't be documenting the internals.

Evil. But I suppose if one were to use the kick-behind oo internals, one
_really_ commits to the ElevateDB, forever and ever and ever. It'd
depend on the project, I suppose...but it's tempting, if the speed
advantage is so huge.

Tim,

Just noticed that EDB is BDE spelled backwards - not sure
what conspiracy theory to attach to that

Sean

Tim Young [Elevate Software] wrote:
> Dom,
>
> << Hasn't DBISAM always been fully object-oriented? >>
>
> Yes, and no.  It is partially OO internally, but a lot of the objects simply
> wrap a set of procedural routines in a way that mimics a lot of the BDE's
> functionality.
>
> << In what way does ElevateDB improve on this? Maybe a tiny real-word-DB
> coding example...?  >>
>
> Here's an example of using the bare-bones calls to the engine to open a
> table and navigate it, putting the second column value of each row into a
> label's caption:
>
> procedure TForm1.NavigateButtonClick(Sender: TObject);
> var
>    TempEngineManager: TEDBEngineManager;
>    TempSessionManager: TEDBLocalSessionManager;
>    TempDatabaseManager: TEDBDatabaseManager;
>    TempCursor: TEDBCursor;
>    TempCursorRow: TEDBCursorRow;
> begin
>    TempEngineManager:=TEDBEngineManager.Create;
>    try
>       with TempEngineManager do
>          begin
>          ConfigPath:='c:\testapp';
>          Open;
>          end;
>       TempSessionManager:=TEDBLocalSessionManager.Create(TempEngineManager);
>       TempEngineManager.AddSessionManager(TempSessionManager);
>       try
>          with TempSessionManager do
>             begin
>             Open(TempEngineManager.Environment.ComputerName+
>                  IntToStr(TempEngineManager.Environment.ProcessID),
>                  'MySession','My Session Description');
>             try
>                Login(SYS_ADMINUSER_NAME,SYS_ADMINUSER_PASSWORD);
>                TempDatabaseManager:=TempSessionManager.OpenDatabase('Test');
>                try
>                   TempCursor:=TempDatabaseManager.OpenTable('TestTable');
>                   try
>                      with TempCursor do
>                         begin
>                         TempCursorRow:=CreateRow;
>                         try
>                            First;
>                            while (not EOF) do
>                               begin
>                               Label1.Caption:=Values.Items[1].AsString;
>                               Next;
>                               end;
>                         finally
>                            TempCursorRow.Free;
>                         end;
>                         end;
>                   finally
>                      TempCursor.Free;
>                   end;
>                finally
>                   CloseDatabase(TempDatabaseManager);
>                end;
>             finally
>                Close;
>             end;
>             end;
>       finally
>          TempEngineManager.RemoveSessionManager(TempSessionManager);
>          TempSessionManager.Free;
>       end;
>    finally
>       TempEngineManager.Free;
>    end;
> end;
>
> Of course, all of the engine, session, and database set-up would only occur
> once in the entire application. If you wanted to use a remote session, you
> would just use the TEDBRemoteSessionManager instead and populate the IP
> address, etc. before opening it.
>
> In DBISAM, there would a whole bunch of record buffer allocation (PChars),
> etc. taking place and it is a lot messier, especially when you get into
> dealing with BLOBs, SQL, etc.  With ElevateDB, going directly to the engine
> is not only an option, is it encouraged if you need the maximum amount of
> performance and don't want to use the TDataSet architecture.  However,
> you'll need the source code because, at least initially, we won't be
> documenting the internals.
>