Datensätze einfügen bei autoinc Feldern

[WePo]

Hallo, ich habe eine theoretische Frage zum Datenbankaufbau.
bisheriger Tabellenaufbau: nr(integer),posit(word),datum(date),...
Primärindex auf (nr,posit), u.w. Indices.
Nun möchte ich doch ein Feld lfdnr(autoinc) als Primärindex einführen.
Meine Befürchtung, daß dies zu Schwierigkeiten führen könnte, liegt darin:
Es gibt dann zwei Tabellen mit der gleichen Felder-Struktur
<Sammeltabelle: lfdnr(autoinc), nr(integer),...>
<Arbeitstabelle: lfdnr(autoinc),nr(integer),...>
Beim Jahreswechsel schreibe ich alle Datensätze des vorangegangenen Jahres in die Sammeltabelle und lösche dann aus der Arbeitstabelle alle Datensätze älter als 2 Jahre.
Habe ich mit Schwierigkeiten zu rechnen, falls diese ausgelagerten Datensätze nun z.B. zwecks Prüfung in die Arbeitstabelle zurückgeschrieben werden (müssen)? Von meinem Verständnis her könnte es zu Fehlern führen wenn folgendes ausgeführt wird:

SQL-Code:

insert * into arbeitstabelle (select * from Sammeltabelle where nr not in(select nr from arbeitstabelle) /*ev noch per where eingeschränkt*/);

da die lfdnr der Arbeitstablle ja ein autoinc-Wert ist.
Habe den Code natürlich schon getestet und bisher klappte es ohne exception.
Was denkt ihr?
Werner

[mkinzler]

Bei autoinc-Feldern dürfen diese nicht im Insert stehen also müßte es so heißen:

SQL-Code:

insert posit, datum ,... into arbeitstabelle (select posit, datum , ... from Sammeltabelle where nr not in(select nr from arbeitstabelle)

[WePo]

Danke, ok,
mein erstes Bedenken wird schon bestätigt.
Die Arbeitstabelle sollte ja wegen autoinc neue Werte automatisch einfügen. Dann kommt aber das Problem, daß bei 'order by lfdnr' nun unterschiedliche lfdnr existieren.
Genau das war der Grund, daß ich bisher auf dieses Feld verzichtet habe und nur mit dem kombinierten Index nr,posit gearbeitet habe.
Wäre es dann nicht besser das autoinc-Feld in der Sammeltabelle und der Arbeitstabelle wegzulassen
und zum BSP mit einer Zwischentabelle zu arbeiten, die dann ja durchaus über ein autoinc Feld verfügen kann. Der Zweck für dieses Feld liegt sowieso nur darin den Nachweis führen zu können, daß alle zu prüfenden Datensätze lückenlos vorhanden sind.
Oder wäre es angesagt ein Feld lfdnr(autoinc) zu verwenden, das nicht der Primärindex ist sondern nur indiziert?
Werner

[mkinzler]

Wenn die Sammeltabelle eine Art Archiv sein soll kannst du ja bei sieser ohne autoinc arbeiten und die datensätze 1:1 aus der Arbeitstabelle kopieren oder du erweiterst diese um eine Feld für den PK der Arbeitstabelle.

[WePo]

Ja, ich glaube das mach ich auch so.
Habe gerade schon die Tabellen umgeschrieben.
In der Sammeltabelle ist das Feld lfdnr nun integer.
Da in der Sammeltabelle=Archiv ja keine neuen Datensätze eingefügt werden dürfen, ok abgesehen vom Jahreswechsel , werde ich jetzt testen:
modify Arbeitstabelle.lfdnr(integer),
insert into(...)
modify Arbeitstabelle.lfdnr(autoinc)
Mal sehen was passiert. Wird die Nummer dann weitergeführt?
Wenn nicht versuche ich es halt mit modify Arbeitstabelle.lfdnr(autoinc startwert=)
Gebe Nachricht was war.
Ach so warum dies?
In der Tabelle stehen verbrauchssteuerrelevante Daten. D.h. diese werden vom Hauptzollamt geprüft. Normalerweise- oder eben auch nicht- Anfang des Jahres für das zurückliegende Jahr. Unter anderem verfügt daher die Arbeitstabelle auch über die Daten der letzten 2 Jahre + dem laufenden Jahr.
Ein Zurückschreiben der Daten kann ich aber nicht ausschließen. Daher meine Frage.
Werner

[mkinzler]

Das Verstehe ich irgendwie nicht ganz:

Zitat:

modify Arbeitstabelle.lfdnr(integer),
insert into(...)
modify Arbeitstabelle.lfdnr(autoinc)

Warum veränderst du die arbeitstabelle? Diese würde ich nicht antasten. Ich würde nur die betroffenen datensätze vor dem Löschen aus der Arbeitstabelle in die Sammeltabelle kopieren. Entweder 1:1 (PK Arbeittabelle = PK Sammeltabelle) oder neuen künstlichen Primärschlüssel für die Sammeltabelle.

[WePo]

Hi,
da gerade die Tabelle so wie ich es geschrieben habe geändert und kopiert wird, warum ich so vorgehe.
Das Problem mit dem Feld lfdnr(autoinc) sollte doch wieder auftauchen.
Also ändere ich Arbeitstabelle.lfdnr von autoinc in integer, schreibe die Daten zurück und setze das Feld dann wieder auf autoinc.
Somit dürfte es kein Problem mit autoinc geben and das Anlegen neuer Datensätze dann über eine autoinc Nummer verfügen.
P.S. Datenbank arbeitet noch.
Werner

[mkinzler]

Ich kenne mich mit dem datenbanksystem nicht so aus, aber im Normalfall greift der "autoinc"-Mechanismus nur, wenn das Feld den wert "NULL" hat, schreibst du dort was rein, dürfte es nicht greifen.

[WePo]

Hi,
wie so üblich vergißt man die Hälfte zu sagen was Sache ist.
1. Also, wenn ich das Feld lfdnr wirklich einfüge, so soll dieses dann auch in einer Druckliste erscheinen. Als erste Prüfmöglickeit. Diese Liste muß erstellt werden.
Sie gilt dann aber als steuerrelevanter Beleg, wird also abgeheftet / archiviert, sodaß unterschiedliche Nummern mir den Streß bereiten würden.
2. Diese Anwendung wurde von Paradox auf ABS umgeschrieben. Aus guten Gründen habe ich bei Paradox immer auf autoinc Felder verzichtet.
3. Dieses Programm soll nun eine "sanfte" Überführung von Tabellen auf SQl bieten. Da es aber eine Einzelplatzanwendung ist und sich der Kunde (kleinere Firma) kaum mit Datenbanken auskennt und ja auch nicht so richtig muß nehme ich halt ABS und schreibe nacheinander alles mögliche auf sql um.
4. Dies sind meine ersten Tests nun doch mit einem autoinc-Wert zu arbeiten.
Da mir keine views zur Verfügung stehen arbeite ich also mit Zwischentabellen und dachte mir bringt vieleicht Vorteile beim Datenändern über so was simples wie

SQL-Code:

update Tabelle set feld=wert where autoincnr in (select autoincnummer from zwischentabelle)

Denn "Bald ist schon wieder Weihnachten"
Werner

[mkinzler]

Zitat:

Sie gilt dann aber als steuerrelevanter Beleg, wird also abgeheftet / archiviert, sodaß unterschiedliche Nummern mir den Streß bereiten würden.

Wenn du die Datensätze 1:1 kopierst sollte es keine unterschiedlichen Nummern geben.

[WePo]

Danke erstmal Mkinzler,
werde nun noch ein paar tests laufen lassen.
Ist ja das richtige Wetter dafür. Wie bestellt.
Werner

[Jelly]

Zitat:

Zitat von WePo

Ist ja das richtige Wetter dafür. Wie bestellt.

Ich weiss gar nicht was Du hast... Hier in Köln scheint prächtig die Sonne :-)

Aber mal eine Frage... Warum kopierst Du überhaupt die Datensätze in eine 2. Tabelle und löschst sie dann aus der 1. ??? Lass die doch einfach nur drin. Was hast Du für einen Vorteil daraus?

[WePo]

Jelly ,
aus Wissen um meine Anwender. Datensicherung ist und bleibt halt ein Fremdwort. Also spule ich beim Jahreswechsel die Daten des Vorjahres- ubrigens aus allen wichtigen Dateien - in Sammeldateien in einer zweiten Datenbank. Diese wird gesichert und verschwindet im Schrank.
Sollte nun etwas passieren- du kennst ja den Tenor "passiert schon nichts" - so verfüge ich wenigstens über alle Daten bis zum 1.1. des laufenden Jahres.
Daneben mache ich persönlich alle 6-10 Wochen eine Datensicherung.
Der Anwender ist gehalten zumindest einmal die Woche dies auch durchzuführen. Erfolg:negativ.
Zudem heißt das natürlich auch schnellere Datensicherung, weniger Platz dafür und schnellere Abfragen.
Da in meiner aktuellen Datenbank, nannte sie bisher Arbeitsdatenbank, alle Daten für Vorjahres-/ Jahresvergleiche vorgehalten werden, ist dies auch so ok. Aber man weiß ja nichts genaues nicht. Also kam ich auf die Idee das neue Feld lfdnr(autoinc) einzuführen. Das Rückspulen ist dabei eher ein theoretisches Problem, wird wohl kaum vorkommen, aber s.oben.
Zudem habe ich schon gepostet, daß dies ursprünglich auf Paradox-Tabellen beruhte. Hatte zu viele zerschossene Tabellen mit autoinc-Feld gesehen, so daß ich dieses nie eingesetzt habe.
Doch wenn in 2-3 Jahren eine SQL-Datenbank eingesetzt wird , wird ein autoinc Feld richtig interessant. Für mich bedeutet dies daher zuallererst auch lernen und testen.
Ist a weng länger geworden. Na ja Feiertagsarbeit.
Werner