Subject Re: CANT UNDERSTAND ERROR MESSAGE 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 justified. Mervyn.