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.