FiveTech Support Forums

Silvio,

There are four scenarios we have identified:

1) Do it like most systems do, assign the ID after the new record is saved. Every system I have ever seen uses this method and thus TData was written to work this way.

2) Do like your friend Alfredo does, and use a fake ID on the new record data entry screen. Then aissgn the real ID when saving the new record.

3) Use Nages' system that recovers abandoned IDs and uses them later. This leaves the database with IDs out of physical order, Also, there can be some missing ID's at any given time (did you realize this?).

4) Use my alternate system that shows the real ID on a new data entry screen and just abandons IDs that are created by the user cancelling a new record entry screen. I suggested this BEFORE I knew about your Italian regulations.

Number 1 meets your Italian regulations as near as I can tell.

Number 2 probably meets the regulations too. Users will likely be very confused why the ID on the new record data entry screen isn't always the ID in the record.

Number 3 and 4 probably don't meet the regulations due to lack of sequential IDs in the physical order (not indexed) of the database. Also I believe you have to store the date and time in each record and these would be out of order when you reused abandoned IDs.

Silvio, you have to pick which one you want to use. If you pick something other the number 1 above, then you are going have to write the code for it.

I sold you a product that works very well as is. If you want it to work some other way, that is up to you and you will have to write new code for that. I did not claim that my product would do everything and anything you wanted.

What I would suggest is you go with Number 1 (no new coding involved) for now. You can tell your client that showing the ID on the new screen is an unsolved issue right now, and you don't want to hold up the entire project over it. Later, you can go back and work on it. Meeting the regulations are "must have", displaying the ID on the new record screen is a "nice to have."

Since you will probably only have to write new Load() and Save() methods for the database class to change the behavior of the app, all the data entry screens will automatically inherit the new behavior. This is one of the great things about using objects. If you are not convinced that this will work, I will write up 2 (very simple) different systems as a demo to prove it.

So don't hold up the whole project over how to display the ID on a new record data entry screen.

Mr. James

Very clear and I agree.

Silvio,

Regarding your screenshots of new record data entry screens with IDs, have you tried to figure out what happens if you cancel. Can you cancel one, then add another and see if the second one gets the ID of the cancelled one, a new ID, or?

Are you aware of the concept of voiding? The record is left intact but marked "void" and it is never deleted. This is common practice with accounting software here. I wonder if new records that are canceled are saved in the file and just voided? Maybe you could try this on your demo.

James Bott wrote:Silvio,

Regarding your screenshots of new record data entry screens with IDs, have you tried to figure out what happens if you cancel. Can you cancel one, then add another and see if the second one gets the ID of the cancelled one, a new ID, or?

Are you aware of the concept of voiding? The record is left intact but marked "void" and it is never deleted. This is common practice with accounting software here. I wonder if new records that are canceled are saved in the file and just voided? Maybe you could try this on your demo.

It is right that I will be able to see the last number, that is, only after the rescue, I agree very much

but the question comes spontaneously

if the operator cancels the entry and the Id on sysfile.dbf increases by +1

I will then have an illegal list of invoices with non-progressive numbers

is this normal?
for me it's a crazy shit

this morning I tried to do what you asked me

I used the software Idea program
I entered a new customer (the code is visible on the screen) on a PC
I put a new customer on another computer
then I canceled the insertion on the first one and also on the second pc
I went to check the client archive from dos and saw that there is no record in the archive

then I open new the software and add new record and th enumber is that I try to add before..

that is, what I want James to understand is this:

the error is right in the Tautoincremental class

when entering a new customer, the append () method of Tautoincremental is called

if oSys: found () // if .t. DBF filename was found in the system file
nID: = oSys: id + 1 // increment the key field value by 1

if the saving is canceled by the user there must be another method which cancels the counter, ie it opens the sysfile file and saves

nId: = oSys: = id-1// decrement the key field value by 1

when a user add a new customer have the real number ( no lose any numbers)

is it possible to make it ?

James read last message..where I wrote without sysdbf file
Because the probkem is ......reading extern file

I sad to my customer "the ID displayed is not reliable and could be changed when the cust record is saved."

because I don't have to lose the number if the progressive number I deduce from the last of the same table +1

without using sysdbf.file and autoincremental class

sample:

at init

IF nMode == 1 .or. nMode == 3 // add new or duplicate
oCust: gobottom ()
CCLI: = StrZero (Val (oCust: NumCli) +1.4)

else
cCli: = oRec: numcli // modify
endif

dialog
@ 12, 5 SAY "Code:" OF oDlg SIZE 19, 8 PIXEL
@ 10, 36 GET aGet [1] VAR cCli OF oDlg SIZE 25, 10 PIXEL READONLY

before to save
If nMode == 1 .or. nMode == 3 // add new or duplicate
If oCust: seek (cCli)
oCust: gobottom ()
CCLI: = StrZero (Val (oCust: NumCli) +1.4)
endif
endif

Oreč: NumCli: = CCLI
Oreč: save ()

in this way I should not lose any number if I cancel the save
if instead I use an external file I lost the number