# Abfrage von Autoincrementwerten



## DTR (19. Mai 2006)

Hallo,

ich möchte in eine PostgreSQL Datenbank einen neuen Datensatz einfügen. Dabei soll mir die Datenbank als Primärschlüssel einen Autoincrementwert erzeugen. In meiner Anwendung brauch ich nun diesen Primärschlüssel. Gibt es eine Möglichkeit diesen nach dem Insert nocheinmal abzufragen, ohne eine extra Abfrage gegen die Datenbank auszuführen? Ich habe es bereits mit der Methode getGeneratedKeys() von Statement ausprobiert, diese wird von dem Treiber aber noch nicht unterstüzt. Zur zeit benutze ich den Treiber: postgresql-8.2dev-501.jdbc3.jar.

Gruß
DTR


----------



## bronks (19. Mai 2006)

Wenigstens Mysql bietet eine extra Anweisung, um den letzten in der aktuellen Sitzung erstellten Key zu erhalten, aber diese Anweisung mußt Du auch erst mal an den Server schicken.

Eigentlich sollte man einen Autoincrement nur als RowId verwenden und alle anderen Schlüssel selbst erzeugen. In Businessystemen wird das zwangsweise so gemacht, weil man für eine Belegart mehrere Nummernkreise verwalten muß.

Infos zur vorgehensweise findest Du u.a. in Google wenn Du nach folgendem suchst: "ejb nextid"   .   Auch ohne EJB ist die vorgehensweise die gleiche ...


----------



## Leroy42 (19. Mai 2006)

bronks hat gesagt.:
			
		

> Wenigstens Mysql bietet eine extra Anweisung, um den letzten in der aktuellen Sitzung erstellten Key zu erhalten



Genau das habe ich auch schonmal gelesen und suche verzweifelt danach, googlen (wonach genau :shock: )
hat leider nichts gebracht und ich behelfe mich derzeit mit erneutem Auslesen des letzten
Datensatzes und der hoffnung, daß sich in der Zwischenzeit niemand dazwischengedrängt
hat und mir dadurch ein falscher ID geliefert wird.

Wie heißt die Anweisung?


----------



## Caffè Latte (19. Mai 2006)

LAST_INSERT_ID()


----------



## bronks (19. Mai 2006)

Leroy42 hat gesagt.:
			
		

> ... Wie heißt die Anweisung?


Hier werden 3 Methoden vorgestellt: http://dev.mysql.com/doc/refman/5.0/en/cj-retrieve-autoinc.html

Viel Erfolg!


----------



## DTR (19. Mai 2006)

Hallo,
leider brauche ich in der Tabelle als Primärschlüssel den Auto Wert, da aus den Spalten kein Schlüssel ableitbar ist. Und den Primäschlüssel brauche ich wiederum in der Anwendung als Verweis. Die Verwaltung dieser Autowerte würde ich auch gerne der Datenbank überlassen. Das Problem das ich mit der zweiten Abfrage habe ist, das in der Zwichenzeit ein zweiter User einen Datensatz eingefügt haben könnte und ich würde auch sehr ungerne die Tabelle Sperren, nur damit ich die Zweite Abfrage absetzen kann.

Gruß
Daniel


----------



## bronks (20. Mai 2006)

DTR hat gesagt.:
			
		

> ... sehr ungerne die Tabelle Sperren, nur damit ich die Zweite Abfrage absetzen kann ...


Jetzt würde mich interessieren, was Dich zu dem gedanken treibt?


----------



## Reinski (8. Jun 2006)

Hi Leute,

ich habe genau das selbe Problem, mit exakt den selben Bedenken hinsichtlich der last()-Methode und einer möglichen Gleichzeitigkeit von Inserts.
Bin ein frischer Umsteiger auf Java und eigentlich dachte ich, das wäre ein Allerwelts-Problem und super einfach zu lösen (ich meine, wieso geht das in anderen Sprachen ohne Probleme?).

Ehrlich gesagt, kann ich nicht glauben, dass es dafür in Java keine _wasserdichte_ Lösung geben soll, außer den Auto-Wert per DB-spezifischem SQL festzustellen. Deshalb wollte ich diesen Thread nochmal bisschen pushen. 

Hat vielleicht doch noch jemand eine Idee?

Kann man ein ResultSet evtl. so einstellen, dass es ausschließlich eigene Inserts sieht, aber keine Inserts von anderen? Dann würde die Sache auch mit move() sicher funktionieren.
Für Hilfe wäre ich sehr dankbar.
Gruß!

reinski


----------



## Leroy42 (8. Jun 2006)

Reinski hat gesagt.:
			
		

> Kann man ein ResultSet evtl. so einstellen, dass es ausschließlich eigene Inserts sieht, aber keine Inserts von anderen?



 :shock: Was soll denn das für eine Datenbank sein  :shock:


----------



## bronks (8. Jun 2006)

Reinski hat gesagt.:
			
		

> ...wieso geht das in anderen Sprachen ohne Probleme? ...


Welche Sprachen und welche Probleme?

Was soll Dein Autowert darstellen und was willst Du mit diesem machen?

Autowerte werden dauernd für irgendwelche Zwecke mißbraucht, für welche sie nicht gedacht sind und dann wundern sich die Leute, daß es unerwartete Probleme gibt.


----------



## Reinski (8. Jun 2006)

bronks hat gesagt.:
			
		

> Welche Sprachen und welche Probleme?


Öhhm, das Problem, über das hier diskutiert wird lautet:
Wenn ich eine Tabelle mit einer AutoInkrement-Spalte (=Autowert) habe und per 
	
	
	
	





```
ResultSet.moveToInsertRow();
ResultSet.updateXxx(...);
...
ResultSet.InsertRow();
```
einen Datensatz einfüge, wie kann ich dann den generierten Autowert für diese Zeile mit 100%-iger Sicherheit auslesen.

Welche Sprachen? Ok, Du hast Recht, das ist eigentlich keine Funktionalität der Programmiersprche an sich, aber das ging schon mit dem oft verlachten VB6 und seinen RecordSet-Objekten. Da hatte man nach dem Insert direkt den Autowert im entsprechenden RecordSet-Feld und konnte ihn von dort auslesen. Meines Wissens ging das für alle Datenbanken...



			
				bronks hat gesagt.:
			
		

> Was soll Dein Autowert darstellen und was willst Du mit diesem machen?


Die Autowert-Spalte ist der Primärschlüssel der Tabelle (die ID der Datensätze) über den Beziehungen hergestellt werden. Ich generiere die IDs nicht selbst, da ich gerne der Datenbank die Arbeit überlassen möchte, die sie am besten kann, nämlich die Generierung eines für diese Tabelle eindeutigen Wertes.



			
				bronks hat gesagt.:
			
		

> Autowerte werden dauernd für irgendwelche Zwecke mißbraucht, für welche sie nicht gedacht sind und dann wundern sich die Leute, daß es unerwartete Probleme gibt.


Darf ich mal zurück fragen, was Du sonst mit Autowerten machst?
Falls meine Verwendung einen Missbrauch darstellt - inzwischen nimmt man ja lieber GUIDs statt fortlaufende Nummern - wie muss ich da ansetzen? Gibt es da z.B. DB-unabhängige Methoden von JDBC-Objekten?

Gruß!

reinski


----------



## Reinski (8. Jun 2006)

Leroy42 hat gesagt.:
			
		

> :shock: Was soll denn das für eine Datenbank sein  :shock:


Verstehe deine Verwunderung nicht ganz. Ich bin aber ja auch kein DB-Experte, der die Interna der diversen DB-Engines kennt. Immerhin musst du mir zustimmen:
1. Es gibt ResultSets, die keine Kenntnis von Änderungen in der DB erlangen. Der Vorteil liegt in der hohen Performance, weil DB-Operationen anderer User nicht dem resultSet mitgeteilt werden müssen.
2. Es gibt ResultSets, die Kenntnis von Änderungen in der DB erlangen. Vorteil ist die Flexibilität, Nachteil die schlechtere Performance.

Und ich hatte halt nur die Idee, dass es noch ein Mittelding gibt, so ein ResultSet wie unter 1. beschrieben, das aber um neue Zeilen erweitert wird, wenn man über das resultSet selbst neue Datensätze einfügt. Das könnte ja sogar unabhängig von der DB realisiert sein. War der Gedanke _so_ abwegig.?   
Gruß!

reinski


----------



## bronks (8. Jun 2006)

Reinski hat gesagt.:
			
		

> ... Öhhm ...


Das VB ist schon gut, aber dafür ausgelegt, daß es für den Programmierer einfach ist. Das RecordSet macht sehr viele Sachen automatisch, welche man aus Performancegründen evtl. nicht automatisch haben möchte.

Daß Du mit Autowert einen Primärschlüssel erzeugst, das glaube ich Dir, aber was sagt dieser vom Inhalt aus? Auftragsnummer? Buchungsnummer? Lieferscheinnummer? Verrate mir das und ich sage Dir dafür, ob das einen Missbrauch darstellt und welche möglichen Nebenwirkungen Du erwarten kannst.

Ich verwende Autowerte nur als RowId, wenn diese gebraucht werden. Zu GUID würde ich auf jeden Fall raten. Wie ansetzen: Such mal in Goolge nach den beiden ganz oben gennanten Suchbegriffen. Auf der ersten Ergebnisseite geht es nur um das Thema. Im Wikipedia steht zu GUID auch ein sehr erleuchtender Satz.


----------



## Reinski (8. Jun 2006)

Meine IDs sind einfach nur Zeilen-IDs. Ich hab das noch aus alten Zeiten, wo die Datenbanken bei Beziehungen/Indices über LongInteger-Werte schneller waren als über Strings und es die GUIDs noch nicht gab.
Die IDs haben für den Datensatz keinerlei Bedeutung.

Danke für die Hinweise! Werd ihnen mal nachgehen... ;-)
Gruß!

reinski


----------



## Reinski (8. Jun 2006)

bronks hat gesagt.:
			
		

> Im Wikipedia steht zu GUID auch ein sehr erleuchtender Satz.


Hehe, der mich erleuchtende Satz stand aber unter UUID: 


> Die Release 5.0 von Java stellt eine Klasse zur Verfügung, die 128-bittige UUID generiert.


Und die heisst java.util.UUID. Dann werd ich morgen die Sache mal ausprobieren.
Vielen Dank nochmal für Deine Hilfe!
Gruß

reinski


----------



## thE_29 (9. Jun 2006)

```
PreparedStatement ps = conn.prepareStatement("SELECT nextval(?)");
    ps.setString(1, seq);
```


Wobei seq für den Namen des Increment Ding steht!

Bei mir wäre es tabelle_seq

Dh, du könntest auch gleich sagen "SELECT nextval('tabelle_seq');



Nachtrag: Also ohne ein statement absetzen geht das nicht... Bzw isses dann eben spezifiziert in den Treibern, aber wenn eh nur DU in der Datenbank adden tust, musst du 1mal auslesen und dann den counter immer adden!



Edit2: machs so 

Insert into tabelle (col1,col2,...) values (1,(select nextval('tabelle_seq')),....)



so gehts, habs grad ausprobiert


----------



## SamHotte (9. Jun 2006)

Wie wäre es, wenn du deine drei SQL-Befehle in eine Transaktion kapselst? Normalerweise sorgt dann das DBMS dafür, dass ein weiterer lesender oder schreibender Zugriff nur korrekte Zustände sieht ...


----------



## bronks (9. Jun 2006)

Reinski hat gesagt.:
			
		

> ... Hehe, der mich erleuchtende Satz stand aber unter UUID:


Ich meinte eigentlich die Erwähnung der zentralen Registrierungsstelle (Registrierungstabelle).


----------



## Leroy42 (9. Jun 2006)

Reinski hat gesagt.:
			
		

> Und ich hatte halt nur die Idee, dass es noch ein Mittelding gibt, so ein ResultSet wie unter 1. beschrieben, das aber um neue Zeilen erweitert wird, wenn man über das resultSet selbst neue Datensätze einfügt. Das könnte ja sogar unabhängig von der DB realisiert sein. War der Gedanke _so_ abwegig.?



Wohl doch nicht, wenn du es so beschreibst ist es mir schon verständlicher.


----------



## thE_29 (9. Jun 2006)

Falls es vorbeigegangen ist, so kann man es mit 1 befehl machen:


```
Insert into tabelle (col1,col2,...) values (1,(select nextval('tabelle_seq')),....)
```


----------



## Reinski (10. Jun 2006)

thE_29 hat gesagt.:
			
		

> Falls es vorbeigegangen ist, so kann man es mit 1 befehl machen:
> 
> 
> ```
> ...


Sorry, dass ich erst jetzt wieder rein schaue, aber ich war etwas beschäftigt... :-/

Ich verstehe nicht ganz, wo hier der Vorteil liegt. Mit dem SQL-Befehl würde man doch einfach den nächsten Autoinkrement-Wert auslesen und eine neue Zeile mit diesem Wert (explizit) anlegen, oder?
Da kann man doch auch gleich ein normales Insert machen, ohne einen Wert für die Autoinkrementspalte anzugeben, dann macht die DB die Arbeit und das Ergebnis ist genau dasselbe.

Vor allem aber ändert sich nichts an der Tatsache, dass ich danach immer noch nicht den Autoinkrementwert kenne, sondern ihn erst noch durch einen zweiten Zugriff feststellen muss.

Allerdings wäre der Vorschlag, das ganze in eine Transaktion zu packen, eine Prüfung wert... ;-)
Gruß!

reinski


----------



## thE_29 (12. Jun 2006)

Na dann habe ich das falsch verstanden 

Jedenfalls kriegst du halt mit select nextval(..) den Wert raus!

Du wirst net über 2 Statements hinauskommen...


----------

