[SQL] Client and server cursors

[gary hayenga]

>
I don't see a problem if you have the option to do this.  An editable 
cursor would be very handy for many people.

We need to use the SQL method since ours is a database independent RB 
application and are looking forward to making Valentina Server an 
option along with Frontbase and Openbase.  If it supports everything we 
need to do, i.e. SQL92 compatible implementations of transactions, 
subqueries, outer joins, alter table, foreign key constraints, etc.  
Then the I personally think Valentina's speed advantage will make it 
very attractive.

gary hayenga


> Message: 4
> Date: Tue, 04 Mar 2003 23:08:35 +0200
> From: Ruslan Zasukhin <sunshine at public.kherson.ua>
> Subject: [SQL] Client and server cursors
> To: <valentina at lists.macserve.net>
> Message-ID: <BA8AE273.20C27%sunshine at public.kherson.ua>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> Hi guys,
>
> Just want discuss a little issue of cursors for Valentina Client.
>
> As some of you know mySQL and Postgre, have client-side and server-side
> cursors.
>
> When e.g. MySQL create client-side cursor this means that found N 
> records
> are transferred to client into its RAM, and there is no more overhead 
> on
> Server side.
>
> Now you can ONLY read records of this cursor.
>
> IF you want change or add or delete some record of this cursor, you 
> need
> send to server OTHER SQL command as
>         "INSERT ... " or
>         "UPDATE .. WHERE ID = N"
>         "DELETE .. WHERE ID = N"
>
> -----
> What we try now implement for Valentina is ability to use the SAME 
> cursor
> API, that we use for local dbs.
>
> So this looks as
>
>     curs = db.SqlSelect( "SELECT ...", ReadWrite, kClient )
>
> Now if you want do modifications of records you can do simply:
>
>     curs.Stringfield( "name" ) = 'something new'
>     curs.Update();  <<<<<<<< this send command to server.
>
> €€>> What you think about this approach ?
> €€>> Anybody see any potential problems with this ?
> **>> I do not remember if any other db use this way? IT seems I have 
> see
> always generation of new SQL command in background...
>
> -----
> As for me I think this is really MORE EASY and more comfortable way,
> Then generate new SQL string for command.
>
> And this looks to be more effective, because again,
> -- you do not spend time and resources to build SQL string
> -- server do not spend time to parse it.
>
> Data simply go by special protocol in binary form from client to 
> server.
>
>
> -- 
> Best regards,
> Ruslan Zasukhin      [ I feel the need...the need for speed ]