Autoincrementing error 0

[terryd]

This is a showstopper for me but there must be some solution since I am sure this is a common occurrence.
Nettalk 4.46.TPS database (will be converted to SQL before deployemnt)
I have a form where one (or more) of the fields are required as an entry and is a unique key .
I insert a record in which the ID field is autoincremented.
The record is created in the tps database with the id autoincremented and the above required unique field is blank.
The client whilst in the form and before saving or cancelling then selects another menu entry or closes their browser or somehow disconnects from the form
The record is left in that state in the table.
If they then try to insert another record the error message autoincrement error 0 is posted because the value in the required unique  field is blank and the new record has the same value in that field.

[Alberto]

Hi, in TPS if you use the autoincrement function you need to use the Exclude Empty fields in the other unique keys.
Using the autoincrement, clarion adds a new record to the databease before the user can see the form, clarion adds a blanked record (depending on the prime fields), then all the unique keys are added as blank and you cant have more than one single record to be added at a time.
If you use the Exclude empty fields check to the key then it will work.
But... it will NOT work on a Sql enviroment.
In Sql youo will need to use the autoincrement function of the Sql server or do not use the unique in the clarion keys and ckeck the unicity of them manualy.
hope this help
Alberto

[Alberto]

Besides, you can try unchecking the "Prime autoinc if necessary" in the Advanced form tab.

[terryd]

Thanks Michelis
I give the first suggestion a go. I have found another way by adding the autoincrement field to the required field key but all these still leave a situation where rogue records with blank fields are in the table and appear in the browses.
Looks like I will need a cleanup function to remove the bad records.

[kevin plummer]

The other option worth looking at is creating a temp table and only writing the record to your real table when they click the ok button. It is a bit fiddly as you need to load the record and save it and if you are moving to SQL it might not be worth the trouble but it would avoid the rogue records.

[terryd]

Thanks Kevin
Seems strange that there is no real way around these strange records. I was expecting someting like
"Hey stupid this is the way to fix this"