Will v5 allow querying a server database and storing the results in a local
memory table directly? Does v4 already allow this and I just am ignorant.

SELECT * FROM SERVERTABLE INTO Memory\MEMTABLE

It is my understanding that the is the way ADO.NET works all the time.

I am doing a bunch of .SaveToStream and .LoadFromStream stuff right now with
v4 to accomplish this and I know the data image must be duplicated a few
times on the server and client wasting time and increasing memory use. I
just want the best performance I can get.


-Johnnie

Johnnie,

<< Will v5 allow querying a server database and storing the results in a
local memory table directly? >>

No.

<< Does v4 already allow this and I just am ignorant.

SELECT * FROM SERVERTABLE INTO Memory\MEMTABLE

It is my understanding that the is the way ADO.NET works all the time. >>

It may look that way, but there's no way that you can send that SQL to a
remote database server and have it understand it.  It simply has no
knowledge of the client environment.  ADO.NET is simply fetching all or most
of the rows and caching them locally.  That's how ADO has worked for some
time now when you use client-side cursors.

<< I am doing a bunch of .SaveToStream and .LoadFromStream stuff right now
with v4 to accomplish this and I know the data image must be duplicated a
few times on the server and client wasting time and increasing memory use. I
just want the best performance I can get. >>

Actually, if DBISAM were to "do it for you", what you are doing is exactly
how it would do it internally.  The streams are the quickest and most
compact way to send data back and forth from the client to the server and
vice-versa.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:C6264C14-F4F1-480D-8F77-DE344689325E@news.elevatesoft.com...
> << I am doing a bunch of .SaveToStream and .LoadFromStream stuff right now
> with v4 to accomplish this and I know the data image must be duplicated a
> few times on the server and client wasting time and increasing memory use.
> I just want the best performance I can get. >>
>
> Actually, if DBISAM were to "do it for you", what you are doing is exactly
> how it would do it internally.  The streams are the quickest and most
> compact way to send data back and forth from the client to the server and
> vice-versa.

I am always looking for the best performance. With all of my software going
to client/server I need to be certain I am doing the best I can for my
customers.

When I send a query to the server is a physical table created with the
results? Is there a way to get the result table directly (.LoadFromStream)
without creating any physical files?

Here is what I assume is happening when I want to load a query to a local
memory table - correct me as needed:


1. Client: I send a query with Query.Open
2. Server: Creates a table somewhere with the results (memory? disk?)
3. Server: returns table structure and at least one record at current
position to client
4. Client: I use the table structure from the server info to make an empty
memory table
5. Client: I want that whole table the server created - call .LoadFromStream
6. Server: sends the whole thing directly into my memory table

This all looks pretty speedy, except possibly #2.

Thanks,

-Johnnie

Johnnie Norsworthy

The fastest way to handle things like you desire is using Remote Procedures.
It opens the tables in the local HD avoiding network traffic and latency.

> I am always looking for the best performance. With all of my software
> going to client/server I need to be certain I am doing the best I can for
> my customers.
I look in the same way.

> When I send a query to the server is a physical table created with the
> results? Is there a way to get the result table directly (.LoadFromStream)
> without creating any physical files?
It depends on what your query will do. If the requestlive property is true
and result is live then DBISAM just open the physical table or create
another cursor if it is already opened, but if result is not live then
DBISAM create a temporary table in Temp path (from server side) and use it
(changes were not reflected back to original tables unless you code this).

When you talk about *Memory* database in C/S, DBISAM uses only server
memory.

> 1. Client: I send a query with Query.Open
> 2. Server: Creates a table somewhere with the results (memory? disk?)
> 3. Server: returns table structure and at least one record at current
> position to client
> 4. Client: I use the table structure from the server info to make an empty
> memory table
> 5. Client: I want that whole table the server created - call
> .LoadFromStream
> 6. Server: sends the whole thing directly into my memory table
It can be so slow if the amount of records is too high

Eduardo

Hello Tim,

> << Will v5 allow querying a server database and storing the results in a
> local memory table directly? >>
>
> No.

Is it possible to implement it in the future builds ?

--
Charalabos Michael - [Creation Power] - http://www.creationpower.com -
http://www.creationpower.gr

Johnnie,

<< I am always looking for the best performance. With all of my software
going to client/server I need to be certain I am doing the best I can for my
customers. >>

I understand.

<< When I send a query to the server is a physical table created with the
results? >>

If the result set is canned, then yes.

<< Is there a way to get the result table directly (.LoadFromStream) without
creating any physical files? >>

Only with live result sets.

<< This all looks pretty speedy, except possibly #2. >>

It must be done that way because the server must build the result set
somewhere locally first.  It's just the way it has to work.

--
Tim Young
Elevate Software
www.elevatesoft.com

Michael,

<< Is it possible to implement it in the future builds ? >>

Probably not.  Also, I'm not quite sure everyone here realizes that this is
exactly how it is done in every database server out there, with the only
difference being what constitutes a live result set or not.  Some products
can do live joins, for example, while others can't.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:34754BF9-3DB5-4B7D-85DE-6BFCE82BC39D@news.elevatesoft.com...
> Michael,
>
> << Is it possible to implement it in the future builds ? >>
>
> Probably not.  Also, I'm not quite sure everyone here realizes that this
> is exactly how it is done in every database server out there, with the
> only difference being what constitutes a live result set or not.  Some
> products can do live joins, for example, while others can't.

What you don't realize is that we don't care about those other database
servers. We've found our mother duck. And our mother duck can do
ANYTHING.

Thanks for the information!

-Johnnie

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:545D423B-370E-449E-8E6B-B133682EA4AB@news.elevatesoft.com...

> << When I send a query to the server is a physical table created with the
> results? >>
>
> If the result set is canned, then yes.
>
> << Is there a way to get the result table directly (.LoadFromStream)
> without creating any physical files? >>
>
> Only with live result sets.

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.

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

Sorry I am a speed freak but some of my result sets can be quite large.

-Johnnie

Johnnie,

<< What you don't realize is that we don't care about those other database
servers. We've found our mother duck. And our mother duck can do
ANYTHING. >>

Sorry if that was rude-sounding.  It just seems very wrong to me to put
client-disposition information about a result set into the actual SQL.  IMO,
the SQL should not concern itself with implementation issues like that.
It's a different thing to have the engine execute the SQL, and then say
"fetch all".

--
Tim Young
Elevate Software
www.elevatesoft.com