Hi All,

I am in the middle of a re-write of a double entry accounting system I
first gestated some years ago in FM5 (this is third generation). now
FM8, and data separation (of course!)

I have always preferred to initially enter the data in globals in DRAFT
tables (and related draft tables for temp line items...), now in the
User interface file (A. User), then pass the DRAFT data into the actual
table (B. data file) when the Record button is used to confirm the
asssembled record. This allows the pending data to be discarded without
having created an actual final data table record (or related line item
records...). So one does not have to deal with deleting records due to
the user cancelling , and re-establishing auto enter serial sequence
numbers etc. (I just don't like deleting records... and the serial
sequence continuity is one of those immutable concept things)

The deleting and next ID is all straightforward enough in FM7/8 now,
but old habits are comfortable (q.v. die slow deaths) . The downside of
course is that assembling records and line items in user tables then
passing all that data to the 'real' data tables and fields, has
significant scripting, and inevitable greater complexity overall.

What do others think is acceptable these days?

regards

Chris Brown
University of Adelaide

If you don't want to have the user create the record in the actual
table, why not just create a copy of the table, let the user enter the
record there, then import the record into the actual table.
FileMaker 8 allows you to copy paste tables so this should be
relatively simple.

FP wrote:
Hi Fp,

I had thought about it, but I had several months of export/import hell
earlier this year, kind of put me off. Would reduce the script to a
simple thing though

regards

Chris

In article <MiU9f.1259$uQ6.61775 (AT) news (DOT) optus.net.au>,
cbrown (AT) medicine (DOT) adelaide.edu.au says...
I find the extra work of creating multiple tables to contain the same
information in 'different' states is rarely worth the payoff.

There are a couple ways of dealing with your requirements:

1) don't delete - mark them as 'deleted'. The records are still their
for audit purposes forever, holding their serial numbers etc, but
they're zeroed out, omitted from reports, etc.

If the percentage of discarded records is low, this tends to be a great
solution. For an invoice database this would amount to having 'voids'
mixed in with the invoices.

2) delete records, but don't assign the sequential serial number until
the record is moved into an 'accepted' state. It requires manual
maintenance of the sequential number, instead of using filemakers built
in feautres but its Very easy to do -- via a preferences table, or a
dedicated number generator utility table)

For an invoices database this would generally entail having a 2 primary
keys, one containing an autogenerated number used internally, but using
a script assigned serial number for the visible invoice number --
ensuring that number continuity is preserved even if some records are
deleted.

There are also many variations on these themes.

--
regards,
dave

42 wrote:
Hi DAve

I had been defeating the serial ID recently in one solution, and a
slightly problem generating user (an uncanny ability to generate
replicate payments...) by adding DEL to the ID value. Using an
additional Status field consistent whith what you suggest with
'accepted' is reasonable, although requires pushing out solution wide to
'all' rels. A calc field for a 'valid' ID may be an alternative.

I follow your dedicated number generator utility table, I used to use
LUT (Look up Table) sequences quite a lot.

I guess what I have been asking/reconsidering , is more a best
practice/philosophy of design thing.

regards

Chris