Posted by Steve on 10/17/06 20:28

deal. sorry for coming off that way.


"Breklin" <breklin@sbcglobal.net> wrote in message
news:STaZg.642$T_1.476@newssvr14.news.prodigy.com...
| Steve, why don't you offer advice instead of criticizing mine. My point
| was, that she should have both and I am trying to say that she needs to
| have both. One id for each row that is auto incremented by the database
| and another that is from a form field that allows her to enter in an
| alpha-numeric code.
|
| I have already posted a possible solution for her to check for
| duplicates. Please read and add to it if you like but let's refrain from
| refuting everything I offer and try to help her out.
|
| Deal?
|
| Steve wrote:
| > "Breklin" <breklin@sbcglobal.net> wrote in message
| > news:DFaZg.637$T_1.357@newssvr14.news.prodigy.com...
| > |I think the id should be an auto_increment and then she should have a
| > | second field with an index on it for the product code. this would
surely
| > | avoid duplicate records.
| >
| > again, unless SHE is assigning product id's they will *rarely* be
integers
| > that can auto-increment. if the user is specifying the product id, then
| > showing the user the failed sql error message is less than elegant.
| > especially if she can look up the id first, before trying to perform the
| > insert. i gave an example early in the thread of how all this can be
handled
| > without php thrown errors.
| >
| > the auto-incremented id is great and should be on every table as a rule
of
| > thumb. but again, this does NOTHING to solve her problem of duplicate
data
| > based on produce code/id. again, i gave an example.
| >
| > cheers.
| >
| >
| >

[Back to original message]