INSERT and beginAppend()

I have seen in several places here advice on using INSERT and UPDATE instead 
of beginAppend() and beginEdit() when working with SQL Server.  Can you 
explain to me why this is the recommendation?  What issues or problems arise 
with the data objects approach that has caused a switch to pass-through SQL 
commands directly to the server?  It just seems to me that the data objects 
approach was touted as the way to go when the earlier versions of 
object-oriented dBase were released, only to be rejected by some of  you 
knowlegable users.  Please help me understand why this is the case, as 
theoretically the data objects approach seems preferable.

Thanks. 

David,

From my perpespective.  I use MySQL ISAM as my database and table type.  I 
found that "beginAppend( )" caused a lock on the entire table that was
not 
released at the the end with ".save( )".  Any subsequent edit on the
table 
returned a lock error message "record in use by another".  That would
be 
true no matter what record I was trying to edit. Interrestingly enough, the 
lock did not appear if I only used beginEdit( ).  Also while the lock did 
appear after the first "beginAppend( )" it did not prohibit further
appends.

I was able to write in a way that was accepted by the data object as shown 
below.

      if not rf.parent.endOfSet // if not end of set

         if bAppend
            rf.parent.save()       // save row
         else
            /*
              Use update instead of save for edited records.
            */
            q.requestlive = false
            q.active = true
            q.sql = [update ]+cTableName+[ set ]+cSet+[ where ]+cWhere+[]
            q.requery()
            q.active = false
         endif

However since I was not looking for a return rowset it was just as easy to 
use the db.executeSQL( )

db.executeSQL([delete from company where id = ']+myKey+['])

I submitted a Qaid to dBase on this issue and they accepted it, but never 
did anything to resolve the matter.  Andre may have some other pearls of 
wisdom on this issue, but I suspect this may also be a problem in FireBird 
when used with dBase?

Claus






"David M. Polinger, MBA, CPM" <DPolinger@DataSolutionsInc.net>
wrote in 
message news:x9LTR7$bIHA.1952@news-server...
>I have seen in several places here advice on using INSERT and UPDATE 
>instead of beginAppend() and beginEdit() when working with SQL Server.  Can

>you explain to me why this is the recommendation?  What issues or problems 
>arise with the data objects approach that has caused a switch to 
>pass-through SQL commands directly to the server?  It just seems to me that

>the data objects approach was touted as the way to go when the earlier 
>versions of object-oriented dBase were released, only to be rejected by 
>some of  you knowlegable users.  Please help me understand why this is the 
>case, as theoretically the data objects approach seems preferable.
>
> Thanks.
> 

In article <x9LTR7$bIHA.1952@news-server>, 
DPolinger@DataSolutionsInc.net says...
> I have seen in several places here advice on using INSERT and UPDATE
instead 
> of beginAppend() and beginEdit() when working with SQL Server.  Can you 
> explain to me why this is the recommendation?  What issues or problems
arise 
> with the data objects approach that has caused a switch to pass-through SQL

> commands directly to the server?  It just seems to me that the data objects

> approach was touted as the way to go when the earlier versions of 
> object-oriented dBase were released, only to be rejected by some of  you 
> knowlegable users.  Please help me understand why this is the case, as 
> theoretically the data objects approach seems preferable.
> 
> Thanks. 
 

David,

I'm still learning this stuff, so wait for more informed replies. But, 
from what I see so far, you can continue to use beginAppend() and 
beginEdit() as long as you don't have specific issues like Claus. Some 
of the suggestions to use SQL are probably due to people being SQL 
purists. Others may have encountered a problem with doing things via the 
BDE. I don't know for certain at this point, but I could see there being 
performance issues since pass-through SQL really does just pass a simple 
string to the server for it to process whereas the BDE has to setup and 
manage a transaction when you use beginAppend/Edit.

I'm guessing, but using INSERT/UPDATE SQL statements /may/ also allow 
you access to field types which the BDE does not support itself.

You also get the benefit of being able to use one SQL statement to 
UPDATE a whole bunch of rows - much like the old dBASE REPLACE command. 
Depending upon the server you are using, you can also achieve the APPEND 
FROM result of dBASE by using the INSERT command with a SELECT clause.

-- 
Geoff Wass [dBVIPS]
Montréal, Québec, Canada

.|.|.|        dBASE info at http://geocities.com/geoff_wass       |.|.|.
.|.|.| ---------------------------------------------------------- |.|.|.

David M. Polinger, MBA, CPM schrieb:
> Can you 
> explain to me why this is the recommendation?  What issues or problems
arise 
> with the data objects approach that has caused a switch to pass-through SQL

> commands directly to the server?  

As Geoff already wrote, you _CAN_ continue using beginedit() 
beginappend, and - as a general rule - all other rowset methods.

The point is, that you should make this time using the old methods as 
brief as possible, because they have a high potential of making a lot of 
trouble.

What you need to understand as the basic rule is that ALL rowset-events 
and methods are operating on LOCAL datasets. If you have a live link to 
an SQL server, the rowset will nevertheless be fed from local RAM or disk.
BDE is arranging for all necessary synchronization with the back end.

But the BDE just has its limits; and that's where the problems do come from.