AutoIncrement mit FireBird

[TurboMagic]

Zitat von Marco Steinebach:

Hallo zusammen,
Erstmal ganz herzlichen Dank an alle für die Antworten. Meine Güte, , ich glaube, ich muss mal meine Suchmaschine reparieren, die Links, die bei euch gleich oben standen, hat google mir nicht ausgespuckt - oder es war schon zu spät nachts.
Jedenfalls hab ich's jetzt verstanden.

Aber trotzdem nochmal eine blöde Frage:
Ich hab noch nicht wirklich verstanden, warum ich die DB nicht mit meinem Programm erstellen soll, gut, wenn ich gleich eine DB mit ausliefere, die toll ist, wird mein Quell-Code natürlich entsprechend kleiner, weil die ganzen Befehle da nicht drin sind, soweit so klar.
Mein Kunde hat also Version 1.5 meines Programms, und version 1.5 der passenden Datenbank.
Wo kommt die überhaupt hin, eine Tabelle für sowas?
Jetzt gibt es die Version 1.6.
Dafür müsste, die Datenbank 1.5 des Kunden, einige Änderungen machen, die aber, so sagt ihr, nicht mein Programm macht...
Sondern wer?
Also auf deutsch, V1.5 hat bei den Adressen noch keinen Spitznamen, die V1.6 schon.
Ich hätte jetzt einfach in mein Programm ein Alter Table gemacht, falls es die Spalte "spitzname" nicht gibt.
Wie macht ihr das?

Ich bin echt gespannt und grüße herzlich
Wandogau

In meinem Fall nutzt jede Installation des Programms eine lokale DB,
weil viele die Daten in der DB zentral nicht wirklich sinnvoll sind und die Anwendung
auch ohne Netzwerkverbindung laufen muss.

Bei einem Update bringt der Installer eine neue DB Datei mit, die aber nicht so heißt wie
die produktiv benutzte. Mittels einem selber geschiebenen Sync Programm werden dann die Daten
aus der alten Datei in die neue kopiert und dann die neue Datei benutzt.

Das Sync Programm kann auch ggf. nötige Anpassung an Daten vornehmen, dazu gibt's in der
DB Datei eine eindeutige Versionskennung die dann ggf. den entsprechenden Vorgang triggert.

Grüße

TurboMagic

[Neumann]

Das kann man machen, neue Datenbank mit den "Alten" Daten füllen und dann die neue verwenden. Ist aber wesentlich aufwendiger als die Bestehende zu ändern. Fehler sind natürlich auch möglich, etwa wenn man vergisst die Tabelle X zu füllen usw. .

Einmal ist wohl kein Problem, aber was ist wenn der Benutzer 4 Updates auslässt und gleich von 1.5 auf 2.0 geht?

Ich würde es nicht so machen. Wir lassen bei jeder Versionsänderung die ganze Datenbank prüfen und alle Tabellen, Proceduren, Trigger usw. wenn nötig anpassen. Dauert manchmal etwas und kann auch teilweise fehlschlagen, wenn z.B. kein exklusiver Zugriff auf die Datenbank gegeben ist. Ist aber sonst recht sicher und man kann den Vorgang auch mehrmals durchführen wenn es nicht gleich klappt.

[Marco Steinebach]

Hallo zusammen,
Ich hab mich damit jetzt mal beschäftigt, und gleich noch ein Problem, oder eine Frage:

Code:

create table objects (
  id integer generated by default as identity primary key,
  name varchar(15)
);

Als ich meine Id noch selbst gefüllt habe, konnte ich einfach sagen:

Code:

insert into objects values (17, 'Test');

Die Id-Spalte füllt er jetzt selber.
Klar nun kann ich schreiben:

Code:

insert into objects (name) values ('Test');

Das funktioniert auch, aber mach das mal mit, sagen wir, über 20 Spalten...
Gibt es eine Möglichkeit beim Insert die ganze Bennennung der Spalten wegzulassen, aber so, dass er die Id selbst ausfüllt. Also sowas wie:

Code:

insert into objects values ({übergeh_die_Spalte},'Test');

Wenn ich ALLE Spalten beim Insert angeben muss, nützt mich das ganze schöne Auto-Increment nix.

Herzlich grüßt
Moo

[Olli73]

Gib als Wert NULL an.

[himitsu]

Nein, denn "NULL" heißt "schreib NULL in das Feld" und der Generator wird garnicht verwendet.


Es gibt einige DBMS, da kann man "DEFAULT" in INSERT-Statements benutzen.

Ansonsten werden Default- oder AutoInc-Definitionen nur dann verwendet, wenn das Feld eben nicht im INSERT-Statement drin steht.

SQL-Code:

INSERT INTO objects (name) VALUES ('Test'); 
INSERT INTO objects (id, name) VALUES (DEFAULT, 'Test');

INSERT INTO objects (name)
VALUES
  ('Test1'),
  ('Test2'),
  ('Test3'),
  ('Test4');

Zitat:

insert into objects values (17, 'Test');

Sowas macht man eh nicht, also ohne die Feld-Definitionen, denn das knallt schnell mal, wenn die Felder in der DB nicht der "erwarteten" Reihenfolge entsprechen, oder gar mehr Felder vorhanden sind.
Passiert z.B. gern mal bei Updates/Upgrades, wenn man über die Jahre die DB-Struktur anpasst, und Felder hinzufügt/entfernt/umbenennt/........

[Marco Steinebach]

Huhu Himitsu,
Gut, , dann schreib ich's doch um - 'grummel!
Herzlichen Dank!