[WD23] Automatic Id key stopped working!

Hi all and a happier new year to everybody here!

My new year started with a less happy experience. Suddenly, after several years of problem-free operation, one of my batch procedures stopped working, because the automatic ID generation by Windev did not work any more! It wanted to use an Id already used in the previous batch process a month ago, thus generating a duplicate error. Then I tried adding a test record manually in the Windev WDMAP application, and it repeated the exactly same error, using the same old Id.

I found no reasonable explanation for the problem, but I fixed it by first reading the last record of the file, adding 1 to its ID-value and then assigning it to the new record before doing the HAdd(Filename,hForceIdAuto). This works. Earlier just a plain HAdd(Filename) was enough to write the record.

Usually I maintain the Ids in a separate control file, but in some newer files I have started to use the Automatic Id. But Obviously Windev's Auto ID is not reliable? Has anybody else had similar cases?

Best regards
Ola

Hallo Ola,
we had the same problems, so we switch to MariaDB. It is free and very stable. We never found a reason for this problem.
Christoph

Hello Ola

What base do you use?
HF C / S or HF Clasic

If you are using HF C / S try replacing HF Server 23 with HF22 or HF24



I work in WX 23 version and use HF Server 22, I had no similar problems


further

Enable HTransaction if multiple users access the database at one time

[infosonline.net]



Edited 3 time(s). Last edit at 01/09/2020 04:44PM by infos.

Hi Ola,

seems to be not so much luck for this year, my heart's bleeding with yours ...

1 - switch to HFSQL v25 (from the French web site)

2 - if you're using this key just as a key and not for PC Soft's replication then switch to GUIDs or to keys which are inherently unique like SysDatetime + customer# + ... Put the building of the key or of the GUID into a trigger subroutine (on write) and everything will work until the end of time.

Kind regards,
Guenter Predl
office@windev.at

Hi all,

I could not reach this forum for a day or so?!?!?

Thanks to all replies.
This app is using HF Classic.

I certainly do wish, and I work towards that in my software "everything will work until the end of time",
but with Windev one obviously cannot always expect that to happen

My control file system has (so far) worked for over 3 decades, first with Clarion CPD and then with Windev, and obviously I will have to change all my automatic Ids to work with that. But as long as there are AutoIds in the app, I have to first change the code to do the trick described in my first message (read the last record, add 1 to the Id, and then force it to the new record when Hadding), to avoid this problem in future with other files.

Concerning PCSoft's replication: I've read so much about its unreliability that I really do not have the guts to even to try it

Best regards
Ola

Hello Ola

Take heart. My main app is also running in HF Classic. The database is normalized to the second level and in some cases to the third level so the keys are absolutely critical.
I only use the Auto Id to maintain all the primary keys.
Yes I have had the issue you mentioned but probably about 10 times since I started with Windev at V5.5 I am convinced the problem is not a PCSoft issue but is related to hardware and the reliability of the power at the client site. I am actually amazed at how tough and reliable the HF Classic database has been for me over the years.
Most clients have never had a problem, those that do also experience the need to sometime re-index the files and invariably those clients are in industrial estates or have a their office and workshop - with welders and heavy machinery - in the same building.

Regards
Al

Hi Ola,

From the top of my head: Did you try re-indexing your table and flagging the 'delete inactive records (deleted or crossed)' (or something like that).
If you didn't do so even deleted records primary unique ID keys will still be 'used' somehow I believe.
This will clean up deleted ID's that have bene used previously.

Cheers,

Peter Holemans

Hi again and thanks Al and Peter

Al, it's a total showstopper when an AutoId does not work. How do you manage such situations?

I find it hard to claim the local electrics system; certainly it is not overloaded as we have one of the mildest januaries here in a century and has shown no signs of bogging down. Also, when testing, I got the exact same problem both in a very old XP machine (which has not shown any other marks of getting tired...) (production database) and in a newer Win 7 machine (test database).

Peter, I did run re-indexing (with default settings), and I even deleted the index files, and let the system re-build them again. This did not help. There are no deleted records between the latest record and the older record whose Id the AutoId wanted to use.

Today I also found another file with the same problem; adding is no longer possible, so I have to change the code to manually maintain the Id. Again same problem in XP (production database) and 7 (test database)

Also, there is a (small) problem in finding all the files using AutoId-keys: lot of work. The data file description browse does not help much, as there are only two columns in it (filename and filecaption!!!!) I am missing at least the info on the AutoId, the file abbreviation, maybe also file type, default directory, is it a relation file etc -- you can always hide the unwanted ones. Now I have to check each and every file separately to find the AutoIds. Or is there a better way?

Best regards
Ola

Hi Ola,

For what it's worth:

Quote
Ola
Peter, I did run re-indexing (with default settings)

Default settings don't have the <delete inactive records (deleted or crossed)> checkbox flagged…

Cheers,

Peter

Hi Peter,

Thanks for pointing this out.
I checked the syntac and options of HIndex, and there is one option that faintly refers to what you are saying:

"hNdxDelete" = Re-indexing while deleting damaged records.

But it says nothing about deleted or crossed records, only damaged records.

Is this the one you mean?

Edit: Also found "hNdxCompact" = Re-indexing with compression (keeps the active records only. All the other records are permanently deleted). Maybe this is the one you mean?

Best regards
Ola



Edited 1 time(s). Last edit at 01/14/2020 10:52AM by Ola.

Hi Ola,

Quote
Ola
Edit: Also found "hNdxCompact" = Re-indexing with compression (keeps the active records only. All the other records are permanently deleted). Maybe this is the one you mean

Yep, that looks to be the one.
If you go into the HFSQL Control Center you can also verify all re-indexing options from the file maintenance tab.

Cheers,

Peter H.

PROCEDURE Fehler()
nr1, nr2 are 8-byte int
tx1 is string = HErrorInfo(hErrFile)
tx2 is string = HErrorInfo(hErrItem)
tx3 is string = HErrorInfo()
SWITCH tx3 // All AutoId by me named with ...ID
CASE [=] "duplicate"
IF Right(tx2,2) = "ID" THEN // only if AutoID is incorrect
HSetDuplicates(tx1,tx2,False) // add the record without errormessage
HAdd(tx1) // otherwise the record is lost
nr2 = HRecNum // remember the record number
HReadLast(tx1,tx2)
nr1 = {tx1 + "." + tx2} + 1 // get the correct Auto ID
HRead(tx1,nr2) // read the record
{tx1 + "." + tx2} = nr1
HModify(tx1) // add the record with the new AutoID
HSetDuplicates(tx1,tx2,True)
RESULT opRetry // next Auto ID will be correct
ELSE
Error("Doppelter Key in der Datei : " + tx1 + " im Feld : " + tx2 + CR + "Der Datensatz kann nicht gespeichert werden !" + CR + CR + tx3)
RESULT opCancel
END

CASE [=] "integri"
Error("IntegrityError in der Datei : " + tx1 + " im Feld : " + tx2 + CR + "Der Datensatz kann nicht gespeichert werden !" + CR + CR + tx3)
RESULT opCancel
CASE "<", "U"
IF YesNo("Der Datensatz : " + tx1 + " ist gesperrt. " + CR + CR + tx3 + CR + "Zugriff erneut versuchen ?") = Yes THEN RESULT opRetry
RESULT opCancel
OTHER CASE
Error("Es ist ein schwerer Fehler aufgetreten - das Programm wird beendet." + CR + CR + tx3)
RESULT opEndProgram
END