Sami, That brings up an interesting idea. What if we had a variable RECORDSAFFECTED Which always returned the rows of the target table inserted, updated or deleted, regardless of how the insert, append, update, or delete was accomplished.
It is a VERY handy option in sytems where it is available. It can make for simpler, more bulletproof code. Dennis McGrath ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Sami Aaron Sent: Thursday, July 17, 2008 12:02 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Multi user R:Base on a LAN Dennis - Your method works on an INSERT statement - BUT the APPEND command will still give a SQLCODE = 0 even if there were no records found to be appended - so I always get the value of COUNT = INSERT into one variable BEFORE an APPEND, then compare it to the new value of COUNT = INSERT to be sure the APPEND really generated a new row. Sami ____________________________ Sami Aaron Software Management Specialists 913-915-1971 [EMAIL PROTECTED] From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis McGrath Sent: Thursday, July 17, 2008 10:08 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Multi user R:Base on a LAN Tom IF SQLCode = 0 after the insert then you can test WHERE COUNT = INSERT to get the correct PK. Otherwise you must handle the error. If you ask for WHERE COUNT = INSERT after an error you will get the wrong info. I just tested and SQLCODE is now correctly updated even if the applicable error message is turned off. This is a fairly recent fix. Dennis McGrath ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, July 17, 2008 9:45 AM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Multi user R:Base on a LAN Tom: If your app was designed to be single-user, there's another thing that could mess you up if you move to multiple users in addition to what others have mentioned. Let's say you add a row into a table and want to grab the PK of the row you just entered; in single-user mode you might have used a command like "WHERE COUNT = LAST" ; this won't work because it could grab the row that another user just entered. Instead use "WHERE COUNT = INSERT". Just an FYI, this has bit me a couple times when I run across code that someone else has written! Karen We are moving our internal database project from our single user development machine out to 20 machines and eventually to users not directly connected to our LAN. Using Turbo8 compiler because of several other projects that have been requested. LAN is a mixture of speedy machines and some dogs that will need to be replaced at some point. Server works very well. We expect numerous problems based on the "didn't know I did not know that" paradigm. Our system works great on a single computer and has required "some" changes as we start moving to multiple machines. More will be coming. The differences between single user vs. multi user becomes very obvious once it does not work (particularly in demos) and you have to figure it out. Just part of the learning process. Our question (which may seem very basic): Is there a best way to set up multi-user R:Base on a LAN system? Data is on Drive Y where we can secure direct access from inquiring mice. Is it best for the EXE/DLLs to also be on Drive Y or remain on individual machine's Drive C to access the Drive Y database. We have tried both ways and they work. The concern is LAN speed (particularly for some older computers) and conflicts between tables/temps/views that the software uses. It seemed having one network based EXE that multiple people can access would really effect our LAN speed/memory, while separate EXE/DLLs on desktops isolate some memory processes and be primarily limited to moving data. I have no doubt we have a lot to learn about data and logic conflicts as we go through this. I remain amazed at just how much DYI groups like us can do with R:Base with some time, interest, and willingness to learn.
