How to override filemanager global to autonumber

[koen]

In the dct I have ticked the option autonumber.
In global embeds Primeautoinc /-primerecords or -primefields (after parentcall) I tried to put my own code of autonumbering the field / key.
But the result is the autonumber of Clarion used and not my own code.
What am I doing wrong as to override globally?

Cheers,
Koen

[Rene Simons]

Hi Koen,

Why do you use both methods at the same time.
My guess is that it's asking for trouble.

Rene Simons

[koen]

Hi Rene,
Good question.
As I understand, the way the Nettalk deals with autonumber is different from the way Clarion does. The Clarion templates start by creating an empty record with a value for the autonumber key. Nettalk does not create the autonumber key beforehand. The autonumber key(value) is created when the record is saved. I personally think the Nettalk method is preferable to the Clarion way. Anyway, when in the dictionary autonumber is ticked, Nettalk will take care the autonumbering for you.
What to do if I want to autonumber, and I want to replace the automatic autonumber algorithm with my own algorithm? (In this context 'autonumbering' does not necessary means a sequential number, but it could also mean calculating a unique id / guid).
I thought overriding the autoinc procedure in the global embeds would do the trick. But it seems the templates do the autonumbering somewhere else. So as to answer your question, I do not want to use both methods, but I want to replace it with my own. And the replacement should preferably be at the filemanager level, so that I do not need to code it each time I use the table with the autoinc key.

Cheers,

Koen

[Bruce]

>> As I understand, the way the Nettalk deals with autonumber is different from the way Clarion does.

Sometimes yes, sometimes no. If there is a dependency on the form (like another browse) then the "Insert-at-start-and-change-to-Change-mode" (just like ABC) is done. If not it does the autonumber at the end. (There are overrides on the Advanced tab so you can dictate which approach to use.) Incidentally it's done using the standard ABC FileManager class, since the FileManager class can do this..

>> What to do if I want to autonumber, and I want to replace the automatic autonumber algorithm with my own algorithm? (In this context 'autonumbering' does not necessary means a sequential number, but it could also mean calculating a unique id / guid).

Start by turning off Auto-Number in the dict. And "prime" the value to whatever you like - typically by using the Priming tab.

If you wish to override the algorithm for the FileManager class, you can examine the way ABC does it, then create a derived class with your own algorithm. It's not difficult - but that's more of an ABC question than a NetTalk question.

The very simplest approach is to turn off Auto-Number in ABC, then add code to the global Insert and TryInsert methods in the global fileManager object for that file.

Cheers
Bruce

[charl99]

Koen,

I suggest you keep the auto-number Primary key stuff (even if only in the background) and add a new key, the one you wish to manipulate.  Simply create some 'global' proc to calculate the thing.  A function like MyKey = GiveMeTheNewKey() with parameters if neccessary should _never_ fail if you define it right.

If you are not using a SQL database yet, everybody eventually get there, having a unique key allready defined in the database is, as far as I can understand, quite compulsory.  Might as well put it in now for all files.

Cheers
Charl

[koen]

Hi Bruce,
Thanks for showing me the direction.

Hi Charl,
Thanks for your suggestion.

I have been playing around with autonumber On and Off in the dct.
As I am concerned, if I put the code in the Pre-Insert embed, both cases will be work. I think it is a matter of preference and perhaps old habits.

As to unique keys handling in SQL databases:
If not only Clarion, but also other software (Microsoft / Vb / Django, or whatever) update the SQL database, then indeed the best way is to have the database provide for the unique key.
But if all the programming is done in Clarion, then it might be easier and more flexible to do that in Clarion. When changing to another type of database or to a non-sql database, one does not have to worry about the unique key, because that is all handled by oneself.

Cheers,

Koen