Posted by Andre on 08/23/05 14:28

Actually, it is only important to fetch new table entry as CODE+1
Gaps are OK if user makes them. Skipping order number of CODE by user is
also OK.
But program must always return CODE+1 when new row is added.
User may change the number to any he wishes (except existing one) and the
next new row will be +1
This, of course, is not my idea. I would forbid deleting documents (even law
requires them to be void, not deleted - we are talking about accounting
program)
but then nobody would purchase my program.

"Hugo Kornelis" <hugo@pe_NO_rFact.in_SPAM_fo> wrote in message
news:ipfkg118so3erd23b2sqa65kcsbosi585f@4ax.com...
> On Sun, 21 Aug 2005 23:34:40 +0200, Andre wrote:
>
> There are some conflicting requirements. If there may be no omissions,
> than you must either not allow users to delete a document (or rather:
> don't allow them to delete A ROW - if the corresponding document is
> deleted, keep the row but set a column to indicate that the document is
> deleted) - or you must renumber all documents each time a document is
> deleted to make sure that there never are gaps. Of course, if these
> numbers are visible to the user and used to identify the documents, then
> renumbering them will wreak havoc to the ability to relate rows in the
> database to the actual documents. And if the users don't see the
> numbers, then why bother with trying to keep them without omissions?
>
> Also, if you allow users to change the document number, you are actually
> guaranteed to get omissions. Sooner or later, someone will type the
> number 42 because he's a Douglas Adams fan.
>
> If the actual requirement is to use a number that is PREFERABLY
> increasing and without gaps, and that users can optionally change to
> reuse the number of a deleted document, I'd say: do a SELECT MAX(..)
> query in the front end; increase by one and prepopulate the number field
> in your frontend with that number. The user can either accept this
> default or type a different number. The number that is in the field when
> the user submits his data entry is sent to the database in an INSERT ...
> VALUES statement.
>

[Back to original message]