Benjamin, do you understand the concept of a primary key? In short, it is a field (usually an INTEGER field) that contains a value that is 100% unique for each record. It never changes (unlike a rowid type of value that some db's will create) and therefore can be used to move from list view, to detail view, to update or delete with complete confidence.
Many db's have what is typically called an auto increment feature which is something that automatically assigns the next unique value for a field when an insert is made. I'm not familiar with PrimeBase but I suspect that this feature is available. If it isn't, you can create a counter table and use the logic that was part of the Tango 2000 storefront demo (or I can supply a sample). You add an additional field to your database (say prepaid_id) which contains this unique value or is set to be auto increment. The benefits of a primary key are that you always have a fast way of identifying a record. The field is almost always an INTEGER data type so any searching that the db needs to do (including searching for the right record to update or delete) is much faster than it would be with a field that contained text. You can use the primary key of one table as the foreign key in a related table which takes advantage of the power of a relational database. You avoid the potential of someone changing the value of say the fullname and/or email address at the exact moment between viewing a detail record and deleting it. Based on your current logic, if that were to happen the user trying to make the update would be given a 'Record not found' warning because they are trying to update a record based on values that are no longer current. For more information I suggest you read up on database design and database normalization. Hope this helps, Steve Smith Skadt Information Solutions Office: (519) 624-4388 GTA: (416) 606-3885 Fax: (519) 624-3353 Cell: (416) 606-3885 Email: [EMAIL PROTECTED] Web: http://www.skadt.com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Benjamin Strickland > Sent: August 26, 2002 12:50 AM > To: Multiple recipients of list witango-talk > Subject: Re: Witango-Talk: Running a taf > > > I finally resolved my problem with the help of everyone. In my update > command I had too many Where commands which confused the system. > I changed > the Where command to only two conditions which were based on the > "fullname" > and "emailaddress" and it then worked fine. > > Thanks to everyone who tried to help me. > > Benjamin Strickland > > ----- Original Message ----- > From: "Steve Smith" <[EMAIL PROTECTED]> > To: "Multiple recipients of list witango-talk" <[EMAIL PROTECTED]> > Sent: Monday, August 26, 2002 12:35 AM > Subject: RE: Witango-Talk: Running a taf > > > > That was why I had asked if the table had a primary key. My > guess is that > it > > doesn't, and that is going to cause problems and poor performance. > > > > I'll wait for Benjamin to answer. > > > > Hope this helps, > > > > Steve Smith > > > > Skadt Information Solutions > > Office: (519) 624-4388 > > GTA: (416) 606-3885 > > Fax: (519) 624-3353 > > Cell: (416) 606-3885 > > Email: [EMAIL PROTECTED] > > Web: http://www.skadt.com > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Downall > > > Sent: August 25, 2002 10:50 PM > > > To: Multiple recipients of list witango-talk > > > Subject: RE: Witango-Talk: Running a taf > > > > > > > > > Steve Strickland, > > > > > > Steve Smith is absolutely right. In the event that a user left almost > > > every field blank, and you had changed every include to "false," and > > > you didn't check for valid and sensible data before the insert or > update, > > > then you could conceivably overwrite most of the rows in your table > > > with the values in this update command. But it looks to me like you > > > inserted a row successfully, and don't know what autonumbered > > > primary key value was assigned, so you are trying to update the row > > > by looking for exact matches of virtually everything that was just > > > inserted. > > > > > > My approach, (that I think Steve Smith would approve of, too), would > > > be to do a search (not update) with your same where clause criteria, > > > and make sure there is one and only one row that matches, and > > > thereby retrieve the real primary key and store it in a variable. Then > > > use that in your update command. > > > > > > You can also use Witango's check box to prevent nulls in the fields > > > you are using to identify the row, so that an attempt to update with a > > > bunch of blank fields will generate a warning screen. > > > > > > Bill > > > > > > On Sun, 25 Aug 2002 22:34:30 -0400, Steve Smith wrote: > > > > > > >WARNING!!! > > > > > > > >This is NOT something that you should do with an update action. > > > When you do > > > >that, and there are no values filled into a field, you could > potentially > > > >UPDATE ALL of the records. > > > > > > > >Bill's advice is true for a search action, but not for an UPDATE or a > > > DELETE > > > >action. > > > > > > > > > > > > > > > > > > > ________________________________________________________________________ > > > TO UNSUBSCRIBE: send a plain text/US ASCII email to > [EMAIL PROTECTED] > > > with unsubscribe witango-talk in the message body > > > > > > > ________________________________________________________________________ > > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > > with unsubscribe witango-talk in the message body > > > > > ________________________________________________________________________ > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
