Select and update with lock exclusive

Question

Hello Everybody
In our application we have a table autonum     to handle unique keys for all other tables.
In Autonum we have a column "SUCHBEGRIFF" char(40) unique KEY and a column "WERT" fixed(10,0).
Suchbegriff has values like Rechnungsnr,Auftragsnr,Bestellnr ...
Example:
Befor inserting a record into table rechnungen we do:
Select wert from autonun where suchbegriff = "Rechnungsnr" with lock exclusive.
l_rechnrneu = wert + 1 
update autonum set wert = ?l_rechnrneu where suchbegriff = "Rechnungsnr"
commit
(then l_rechnrneu is used for an insert into rechnungen command)
This technic works for all tables (250) in our application.
We have about 400 concurrent users working with maxdb 7.6 via odbc 7.6
No problems since 2 years!
Now we start some backgroundjobs from an xp-workstation.
We have scheduled 5 jobs, starting every 5 minutes, same time.(Same user,same odbc-connection)
Each job inserts records into a table joblogs and therefore needs a unique JOBLOGNR from autonum.
Now we run into problems 2 or 3 times a day?
<Sometimes the backgound jobs are running (waiting?) without inserting a record into joblogs (deadlock?)
And more worse:
Sometimes the insert into joblogs failes with "duplicate key" ??
We don't know where to begin? Maxdb Problem ? Workstation problem?
Any help welcomed
Best regards
Albert

Answer 1

> >Gosh - that's information overloading at it's best...
> We call this needed information.
> What does our SAP-System? We have 1 mandt,60 accounting areas and about 200 werks!
> Of course SAP uses internal unique keys for all tables, but we configured different "number intervals" for each werks.
With "information overloading" I was referring to the multiple meanings you encode in just one column (your "rechnungs-no").
SAP tables do not have this.
As you wrote, there is "MANDT", "BUKRS", "WERKS" ... and the primary key is defined over all relevant columns.
There is no primary key column where all the different meanings are concatenated together.
So there aren't any surrogate keys here (a.k.a. AUTOID) used here - (ok except the infamous DDLOG sequence...).
> >What do you do, when the value of an invoice has to be changed? Update the primary key of the table?
> Update rechnungen set amount = xyz,...... where rechnungnr = nnn
> We never change rechnungsnr,if the invoice was wrong we produce a credit for it and then write a new invoice
So, you could use a sequence here instead as well.
> > We don't use rollback when fetching logids from autonum.
> >So what do you do, when connection fails, the database crashes or the client application hits an error?
> >You use rollback. There is no way to avoid it.
> >Your application gets a "duplicate key" error - the database performs a rollback of your last action. What does your application do then? Commit?
> Sorry, i meant that we do not do rollbacks over  2 or 3 inserts or updates in different tables.
> SQL-Command,On error = messagebox,errorlog,quit
You don't handle the fetching of the new number in the same transaction as the actual insert of your application data in the same transaction?
> >What isolation level do you use?
> We use DATABASE ISOLATION LEVEL 0
Hmm... did you read the documentation on SQL Locks?
[Internals Course - SQL Locks|http://maxdb.sap.com/training/internals_7.6/locking_EN_76.pdf] :
"Isolation level 0 does not offer any protection against access anomalies."
Basically it might have happened that the same number is read twice.
Perhaps the application is not always requiring locks when reading data from this table?
> After connecting to the database via odbc we do
> =SQLSETPROP(verbindungsnr,"Transactions",2)
> 2 = Transaction processing is handled manually through SQLCOMMIT( ) and SQLROLLBACK( ). Read/write.
> =SQLSETPROP(verbindungsnr,"DisconnectRollback",.T.)
>
>
> So normal select commands are fired without a following commit.
> Insert and update commands are fired with a following commit command.
> Selects from autonum are fired with "look exclusive"
Please be more detailed here.
What is the exact sequence of actions here?
1. Fetch number from number table and update number table.
2. COMMIT
3. Insert new application data with the just fetched number.
4. COMMIT
or
1. Fetch number from number table and update number table.
2. Insert new application data with the just fetched number.
3. COMMIT
And what does your application do with its data when a rollback occurs?
Is it guaranteed that all variables are reset?
> Nevertheless you dislike our design, do you think it would be better (quicker,safer...) to use an internal databases procedure to get
> the next speaking number for a given "suchbegriff" from our autonum table? (no translation of the sql-command every time)
No, currently we don't know what is causing the problem, so we cannot tell whether such a change would help. In fact, right now it would make things more complicated because we would less understand, what's happening here.
Concerning your design: it's not about "liking" or "not liking it".
I just pointed out some problems that result from the design as it is.
> select   wert into :neuerwert FROM "BWPROGI"."AUTONUM"  WHERE upper(suchbegriff)     = upper(:suchkey) WITH LOCK EXCLUSIVE;
> update  "BWPROGI"."AUTONUM" set wert = wert + 1 WHERE upper(suchbegriff)     = upper(:suchkey) ;
> SET neuerwert = neuerwert + 1;
> end;
1. The WHERE clause UPPER(suchbegriff) = UPPER(...) is the best way to disable the efficient use of any index structure. Better make sure that your data is in the right format in the table when you enter it and then look it up without the UPPER() conversion. 
2. I wouldn't perform the increment two times.
Get the current value into your variable, increment this variable, set the current value in the table to the variable.
> A char(10) return value would be nice and i don't know wether this would be the quicker way.
Why should it? You would have to convert it first - that's additional work.
Anyhow, to move ahead with your duplicate keys problem, you may perform a vtrace with the "stop on error" option.
As your error is a duplicate key on a primary key constraint you should set "stop on error" to the error code "200".
The next time your application hits the error, the vtrace automatically stops and we could examine what happened before.
See [MaxDB database trace|https://wiki.sdn.sap.com/wiki/x/2yg] for details on how to activate the trace.
When the error occurs next time and you caught it in the vtrace we can take a look at it.
regards,
Lars