From Mervyn Bick <invalid@invalid.invalid>
Date Mon, 12 Mar 2018 11:32:33 +0200
Newsgroups dbase.getting-started

On 2018-03-11 6:58 PM, Mustansir Ghor wrote:
> Dear Mervyn
> It is because i am still using  dbf tables and opening them directly without using database option. How to use the read write connections with tables. Certainly I would like to use them. I think I am missing out something.

I must say I've never tried updating a JOINed rowset before as I
understood it would be read-only.  I've now reread the OLH and I see I
was mistaken as a rowset with a join CAN be live under certain
circumstances.  See 'live joins' in the OLH.

Keeping a query live and using the rowset's beginAppend(), beginEdit)
and save() methods works well with dBASE because that's the way dBASE
and the BDE were designed.

Keeping a query alive on a SQL server means the server has to allocate
resources to the connection to the detriment of other users.  With many
live queries it can bring the server to its knees.

Very simply, to work with a SQL server one needs to adopt a "hit and
run" approach.  By using a read-only query the server finds the data,
delivers it and after that it doesn't have to wait for the consumers
next instruction for the rowset.  This means that resources for creating
the rowset are only tied up for a very short time and the server can get
on with helping other users.

To update a table one uses the SQL command UPDATE <tablename> or INSERT
INTO <tablename>.  These commands are usually passed to the serve by
using the executeSQL() method of a database object.  Again, the server
is only allocating resources for the very short time it takes to execute
the command.

Applications written primarily for .dbf files take a LOT of recoding
when one wants to move the data to a SQL server.  There is, however,
nothing to stop one from coding for a SQL server but using .dbf files.
It is more work initially but it cuts the work required for conversion
to a SQL server significantly.

To be "SQL server ready" all tables MUST have a primary key.  This is so
that records can be uniquely identified for the UPDATE command.  An
autoinc field does the job nicely.  There used to be plenty of horror
stories about autoinc fields but this seems to be a thing of the past.
Still, regular backups can help cut the risk.

To facilitate the use of UPDATE and INSERT one needs to use a database
object.  The default _app.databases[1].executeSQL() method is there but
it points to tables in the current working directory.  It would be
better to actually place a database object in the form or program and
use that.  (That's good programming practice anyway.)

Don't use datalinked entryfields.  Rather use the rowset's onNavigate()
method to populate entryfields.   Some users use a parameter driven
query with an UPDATE command in the sql property.  After setting the
parameters the query is made active to send the data and then
immediately made inactive so that it doesn't hold up the server.  Others
build a string for the UPDATE or INSERT and submit it via the database
executeSQL() method.  After updating a table requery the query that
displays the data to update the display.

Reasons for moving data to a SQL server would include very large volumes
of data (dBASE has a 2Gb limit on table size) or a large number of users
on a network which can slow down access to data.  If you are certain you
will never need to move to a SQL server then the extra work will not be