Johnnie,

<< So, if I request a live result set and then do a .LoadFromStream it comes
straight from the server with no intermediate files created? That seems like
it would be faster. >>

If the result set is live, yes.

<< What about doing a query that creates a memory table on the server, then
I .LoadFromStream on that and then delete the memory
table? >>

That will work also, but the result set size may become an issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:9598AB3C-0A5E-4EF2-B022-8CAC658E156E@news.elevatesoft.com...
> Johnnie,
>
> << So, if I request a live result set and then do a .LoadFromStream it
> comes straight from the server with no intermediate files created? That
> seems like it would be faster. >>
>
> If the result set is live, yes.

I am going to do some speed tests like this. Thanks for the info.

By the way, I didn't see anything rude you wrote in the other message. I was
just pointing out how we all assume you can do anything we request. YOUR
FAULT!!!!

Have a great weekend.

"Johnnie Norsworthy" <jln206@verizon.net> wrote in message
news:1971F613-4D79-42F1-8A5C-D58DD81B705D@news.elevatesoft.com...
> "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
> news:9598AB3C-0A5E-4EF2-B022-8CAC658E156E@news.elevatesoft.com...
>> Johnnie,
>>
>> << So, if I request a live result set and then do a .LoadFromStream it
>> comes straight from the server with no intermediate files created? That
>> seems like it would be faster. >>
>>
>> If the result set is live, yes.
>
> I am going to do some speed tests like this. Thanks for the info.

My speed test prove using .RequestLive does speed things up a very small
percentage, but if it prevents the server from writing a temporary file to
the disk, then I think it is worth doing just to save wear and tear on the
server drive.

-Johnnie

Johnnie,

<< My speed test prove using .RequestLive does speed things up a very small
percentage, but if it prevents the server from writing a temporary file to
the disk, then I think it is worth doing just to save wear and tear on the
server drive. >>

Well, I wouldn't be *too* worried about that.

--
Tim Young
Elevate Software
www.elevatesoft.com

Johnnie,

<< By the way, I didn't see anything rude you wrote in the other message. I
was just pointing out how we all assume you can do anything we request. YOUR
FAULT!!!! >>

Well, this is more religious than anything, which is why I sometimes feel
like I'm getting defensive.  It can certainly be done, and Eryk indicated to
me via email that there are database engines out there that do it.  I just
don't feel like it is appropriate to handle it in the native SQL.  It just
seems to me that it might cause problems down the road.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<Well, this is more religious than anything, which is why I sometimes feel
like I'm getting defensive.  It can certainly be done, and Eryk indicated to
me via email that there are database engines out there that do it.  I just
don't feel like it is appropriate to handle it in the native SQL.  It just
seems to me that it might cause problems down the road.>>

You don't have to implement it in SQL.  You could do it in a method, something like this:

Instead of :

SELECT * FROM SERVERTABLE INTO Memory\MEMTABLE

You could do:

DBISAMQuery.SQL('SELECT * FROM SERVERTABLE');
DBISAMQuery.Open;

DBISAMQuery.SaveToLocalTable('C:\MEMTABLE'); //New method.

Abdulaziz,

<< You don't have to implement it in SQL.  You could do it in a method,
something like this: >>

Yes, but you can already do that by streaming the query result set to a
local table.  Granted, you have to create the local destination table first,
but the rest is handled by the streaming in DBISAM.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<Yes, but you can already do that by streaming the query result set to a
local table.  Granted, you have to create the local destination table first,
but the rest is handled by the streaming in DBISAM.>>

I am doing that already, but I prefer to have it as built-in method.  That is the beauty of it.

Abdulaziz,

<< I am doing that already, but I prefer to have it as built-in method.
That is the beauty of it. >>

Well, you can always create a library procedure that accepts a source
TDBISAMTable component as a parameter, copies the field defs, etc. and
creates a local version of it, and then streams the contents of the source
to the new local table.  It's probably about 30 lines of code or so:

function CreateLocalTableCopy(SourceTable: TDBISAMTable): TDBISAMTable;
var
  TempMemoryStream: TMemoryStream;
begin
  Result:=TDBISAMTable.Create(nil);
  try
     with Result do
        begin
        DatabaseName:='Memory';
        TableName:=SourceTable.TableName;
        Exclusive:=True;
        FieldDefs.Assign(SourceTable.FieldDefs);
        IndexDefs.Assign(SourceTable.IndexDefs);
        if Exists then
           DeleteTable;
        CreateTable;
        Open;
        TempMemoryStream:=TMemoryStream.Create;
        try
           SourceTable.SaveToStream(TempMemoryStream);
           Result.LoadFromStream(TempMemoryStream);
        finally
           FreeAndNil(TempMemoryStream);
        end;
        end;
  except
     FreeAndNil(Result);
     raise;
  end;
end;

The code assumes that the default session is left as a local session
(SessionName='' for the new table) and that the remote session is a
different session.  Also, be sure to free the table result when you're done
with it.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<Well, you can always create a library procedure that accepts a source
TDBISAMTable component as a parameter, copies the field defs, etc. and
creates a local version of it, and then streams the contents of the source
to the new local table.  It's probably about 30 lines of code or so:>>

I am doing this already I use those two lovely procedures to do the trick:

//V5.00
procedure SaveQueryToLocalTable(const sTableName, sSQL : String);
var
         oStream : TStringStream;

         oQuery  : TDBISAMQuery;
         oTable  : TDBISAMTable;
begin
         oQuery := Nil;

         GetRecord(oQuery,sSQL);

         oStream := TStringStream.Create('');

         oQuery.SaveToStream(oStream);
         oTable := TDBISAMTable.Create(Application);
         oTable.TableName := sTableName;
         oTable.FieldDefs.Assign( oQuery.FieldDefs );
         oTable.CreateTable;
         oTable.Open;
         oTable.LoadFromStream(oStream);
         oTable.Free;

         oQuery.Free;

         oStream.Free;
end;

//V5.00
procedure SaveTableToLocalTable(const sTableName, sDestination : String);
var
         oStream : TStringStream;
         oTable  : TDBISAMTable;
begin
         oStream := TStringStream.Create('');

         oTable := TDBISAMTable.Create(Application);
         oTable.SessionName   := dmAccount.DBISAMSession1.SessionName;
         oTable.DatabaseName  := dmAccount.DBISAMDatabase1.DatabaseName;
         oTable.TableName     := sTableName;
         oTable.FieldDefs.Update;
         oTable.IndexDefs.Update;
         oTable.Open;
         oTable.SaveToStream(oStream);
         oTable.Close;

         oTable.SessionName   := '';
         oTable.DatabaseName  := sDestination;
         oTable.CreateTable;
         oTable.LoadFromStream(oStream);
         oTable.Free;

         oStream.Free;
end;


Please have a look at them and tell me if you can see anything wrong with them.

Regards,
Abdulaziz Jasser