Re: Creating and saving IDs - is there a theory?

paraphrasing the original question: "we need a way to verify that an ID (serial number) is not "faked" the key word is "verify". 1. assuming that the "only degree of verification" is that the serial number was "at one time" generated by your system, and that you indeed have control over the serial numbers being generated, then you could pursue the path purposed of incorporating a checksum-like algorithm as part of the ID which verifies the other part of the ID (and effectively, the reverse). again, this ONLY verifies that "at-one-time" your system generated the ID -- once a valid ID is known, it could easily be faked without further verification, and thus becomes identical to private "passwords" in a public world. the assumption is that no one else in the un-trusted world will know the passord that some ONE(1) other person has been trusted with. Fortunately, if ANY form of further verification is required, then this entire approach becomes REDUNDANT and is probably not worth investing in the added overhead and problems that will be incurred by increasing the serial number's size. this technique is used with banking, because it assumes the number of individuals attempting to forge accounts is many compared to those who know that an algorithm exists for verifying account numbers (perhaps attempting to extrapolate off a known-to-be valid account number), so someone who doesn't know the system will eventually become "creative" and make up their own IDs, thus getting caught. This system is also pretty weak for detecting insider-problems, even with past employees, etc. as, once known, this becomes an ineffective mousetrap. 2. if the verification must be against "known-to-be-in-inventory"-data, then a lookup against a fairly up-to-date table is required. doug's point about creating an application using a simple HASHing algorithm for a "key" lookup would suffice here if the maintainability of this table satisfied your criteria for how "fairly up-to-date" the file was kept. if it becomes expense programming-wise or procedural-wise to insure the table was up-to-date with reality, then you probably want something more integrated with an overall inventory controlled database. For completeness and to state the obvious, you could always utilize a standard default PICK-type file for performing your HASH-method access. 3. if you have a real problem, why do something half-way? having additional verification capabilities is trivial these days, especially when using a scanner or other electronic means. it is nothing to have additional information such as a description, vendor, location, time, even graphics, or other related cross-referencing information -- presented for additional (if not "incidental") verification, including incorporating fuzzy logic for predicting situations outside of "norms" as occuring.