auto increment on Oracle table

Developers Programming
#1

Hello,
I have an oracle table with a trigger/sequence for the auto increment field.
If I edit a new record directly in this table the field value of the primary key is set correctly, so the trigger is working perfectly.

in SC I defined this primary key field in menu -Attributes Values- with -Calculated by the database-. This Primary Key field is not part of the form and defined as NOT -Required-.

When I save a new record I get NO error message but the record is not added. Update and delete is without problem …

Any idea what I’m doing wrong ??

Best regards
Uwe Pfeiffer

#2

Re: auto increment on Oracle table

Hi Uwe,

try Autoincrement (Automatic). From the help:

Auto increment (automatic) - Used just when the database field is AUTO INCREMENT or similar, if your SGDB uses sequences to implement auto increment a field to enter the sequence name is displayed

(ich habe kein Oracle, aber nehme an, das es so richtig ist)

#3

Re: auto increment on Oracle table

Do as RHS said and if is a sequence, dont forget to fill the sequence name on the field that will appear when you select Autoincrement (Automatic).

#4

Re: auto increment on Oracle table

Thanks for your suggestions… but the problem was quite different.
I now made the following solution and it works :

Oracle with only primary key (number) definition… no trigger .no sequence.
In SC I defined -Attribute values- for the primary key as -autoincrement (manual)- and it works correct.

Bit if you put som code in after insert event like sc_exit(sel) … the record is not added … don’t know why…

Regards
Uwe Pfeiffer

#5

Re: auto increment on Oracle table

Hello,

I solved the problem :
1.) define number primary key in Oracle… no trigger
2.) in SC define this field in the form as autoincrement (manual)

If you have some code within afterupdate event … close the code with sc_exit© and not with exit(sel)

Everything works fine.

Best regards
Uwe Pfeiffer

#6

Re: auto increment on Oracle table

Actually you should shame on the Oracle does not do it.
Unfortunately, there is no in Oracle autoincrement columns as MySQL.
Sure it is awkward for Each PK field of a table to create a sequence and trigger them in another NEW.ID (or so) to pass. But the database makes it so self for the correct numbering of the PrimaryKey of the table.
This will then insert statements without any knowledge of the final value of the PK sequence or whose names possible.
You can also (I think) fill in the Oracle Sequence sometime in the gaps in the table that were created by DELETE statements in the table …

Eigentlich soltest Du das bei Oracle nicht so machen.
Leider gibt es In Oracle keine Autoincrement Spalten wie bei MySQL.
Klar ist es umst?ndlich, f?r Jedes PK Feld einer Tabelle eine Sequence anzulegen und diese in einem trigger an NEW.ID (oder so) zu ?bergeben. Aber die Datenbank sorgt dann so selbst f?r die korrekte nummerierung der PrimaryKey der Tabelle.
Damit sind dann insert statements ohne Kenntniss des letzten Wertes der PK Sequence oder deren Namen m?glich.
Au?erdem kann man (glaube ich) bei der Oracle Sequence irgendwann die L?cken in der Tabelle f?llen, die durch Delete Statements in der Tabelle entstanden sind…

#7

Re: auto increment on Oracle table

Hallo,
aber warum sollte ich das feature von SC nicht nutzen…es funktioniert problemlos…

Gru?
Ue

#8

Re: auto increment on Oracle table

Klar funktioniert das. Aber eben nur in Scriptcase. Wenn Deine datenbank mal von einem anderen frontend bedient werden soll, klappts eben nicht mehr. Wenn du alos bspw. Mit einer ASP Seite da ran willst und dort einen neuen Datensatz speichern m?chtest, musst Du auch dort erst den aktuellen squencewert holen und in das Insert-Statement einbauen.
In Oracle mache ich das f?r jede Tabelle so:
CREATE TABLE t_tabellenname (…)
CREATE SEQUENCE seq_tabellenname… liefert den Wert f?r den Primary Key
CREATE OR REPLACE VIEW v_tabellenname
CREATE TRIGGER trgv_tabellenname_eventtyp auf den Tabellenview
CREATE TRIGGER trg_tabllenname_eventtyp eventtyp =(bins, ins, bupd, upd, bdel, del) bins ist BEFORE INSERT, ins AFTER INSERT

In den Frontends, die ich entwickle arbeite ich grunds?tzlich mit den Views. das bringt ein paar nachteile wie z.B. f?r jeden View ein Trigger usw.
Aber auch m.M. nach ein paar Vorteile. Der Tabellentrigger BEFORE INSERT k?mmert sich im Wesentlichen um den neuen Wert des PK.
Der Viewtrigger K?mmert sich um alles was bei dem View gemacht werden muss um Daten zu manipulieren. In JOIN Views oder solche, die Stored Functions verwenden kann man sowieso keine direkten DML Statements absetzen, da muss dann ohnehin ein Trigger her.
Views sind prima geeignet, um Datenbank- und Frontendseite voneinander abzukoppeln. Ich meine damit folgendes: Ich ?ndere die Stuktur einer Tabelle. Neue Spalte(n), ?ndern Spaltenname Spalte1 -> Spalte2 o.?. Damit geht ab sofort jedes direkte Insert-Statement in der Form INSERT INTO ( Spalte1 ) … schief. Nicht so, wenn man mit Views arbeitet. Durch ?nderung des Views (Select SPALTE2 AS SPALTE1) spart man sich die ?nderung des Frontends, da dort ja immernoch SPALTE1 erwartet wird. Klappt nat?rlich nur wenn der Spaltentyp gleich bleibt.
Wie auch immer, ich verfolge immer die Strategie, das ein einfach gestrickter DML - Befehl klappen muss ohne das der absender sich um irgendwelche Werte wie PK-Values k?mmern muss, das muss das DBMS machen.
Schlussendlich vereinfacht das auch die Entwicklung in SC, da sie Insertstatements auch auf Joined Views immer klappen und man, anders als bei MySQL, keine Stored Procedures braucht. Bei MySQL gibt es ja leider auch keine Trigger f?r Views.