I believe he was using R:Base, not primebase, and PrimeBase does have this. It is a "counter" feature. And I agree, every single schema should have a integer primary key for performance/confidence.
Robert. On Sunday, August 25, 2002, at 10:25 PM, Steve Smith wrote: > 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 > -- Robert Garcia BigHead Technology 2781 N Carlmont Pl Simi Valley, CA 93065 Phone 805.522.8577 http://www.bighead.net/ [EMAIL PROTECTED] ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
