Oterro sends this value back to the program that sends an insert or update or delete command to Oterro. So my guess is that R:BASE knows what the number is. It would just have to be exposed to us in a variable.
Bill On Thu, Jul 17, 2008 at 1:33 PM, Dennis McGrath <[EMAIL PROTECTED]> wrote: > 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. > > >
