• Welcome, Guest. Please login.
 
October 21, 2019, 02:19:31 am

News:

Welcome to the SQLitening support forums!


Are you going to post some updates

Started by Mark Strickland, September 15, 2007, 01:56:22 pm

Previous topic - Next topic

Mark Strickland

Paul,

I tried out a few of the early SQLite Client Server examples and I am excited.  Are you going to post more examples as you go?

Thanks, Mark
Mark Strickland, CISSP
www.SimplyBASICsecurity.com

Paul Squires

:)  I sure am! Actually, I had hoped to have another update posted by now. I am working on the caching of rows from recordsets created on the server to the client. Hopefully I'll have that done soon. Once completed with that then I'll upload again.

Paul Squires

.... I am just about finished the caching of rows from the server to the client. It works for a cache size of 1 row but GPF's on larger cache sizes. I just need to find the offending line of code and then the next update should be ready.

I have to say that this caching code was a little hard on my brain because it was hard to keep straight the recordset being dealt with (client side and/or server side) and the fact that code is shared in the common sql3client.dll that is used by both the client and the server applications. At times I got a little lost with what variable I was dealing with at any given time. In the end, it proved to be a nice workout for my brain. :)


Paul Squires

Ok, the cache stuff is now working.... ahhhhhh.... nice to have that finished.

tom cone jr


Paul, congratulations on getting the cache going.  Sounds like it was quite a puzzle.  Care to give us a sneak peek by giving us a high level over view of how it does its magic?   

Paul Squires

Hi Tom,

When it comes right down to the basics, the cache system is really quite simple. It was just getting all the pieces in place to ensure the interaction between the client and the server was correct was the real challenge.

Here is an overview:

(1) sql3_use a database by specifying the new %SQL3_REMOTE flag.

(2) Do an sql3_Select query. The last parameter of the sql3_Select function call is the "cache size" (better described as the number of rows to return from the server whenever the client asks for rows).

(3) Move through your recordset as you normally would. Nothing special happens behind the scenes until you use sql3_rsGet or sql3_rsGetAt. At that time, the client looks at the current position in the recordset to determine if that row has been received from the server. If it has then it simply returns the wanted column information. If it has not then the client request cache number of rows from the server until it satifies the condition.

(4) Continue reading rows in the client and the client continues to ask for rows from the server as required. At some point the client will have received all of the rows from the server. When it satifies that condition then the recordset on the server is destroyed. All that is left then is the client side copy of the recordset. The client side copy exists until sql3_rsDestroy is called.

..... it's as simple as that.  :)