![]() |
AW: Lücken in fortlaufender Nummerierung finden
Zitat:
1,2,4,7,8,9,12,15 hast ist doch ziemlich eindeutig wo die Lücken sind. In einer Stored Procedure ist es auch kein Problem. Eine while-Schleife von 1 bis Max(Tabelle.ID) und schauen ob PK[i] existiert. Falls es in Paradox Stored Procedures gibt, dann ist das wahrscheinlich die einfachste Lösung. |
AW: Lücken in fortlaufender Nummerierung finden
Hier noch eine outer join Variante statt not exists:
Code:
Könnte flotter sein, bin ich mir bei dieser Art der ISAM(?) Datenhaltung auch nicht sicher.
select a.<id>, a. <irgendeinanderesKontrollfeld>,
b.<id> as bid, b.<..> as b<kontrollfeld> from <mytable> a left join <mytable> b on a.ID = b.ID + 1 where b.<kontrollfeld> is null Auch hier gibt es das 1er Problem. Ich denke aber als Indikator für "1 oder mehrere Datensätze fehlen ab hier" reicht es schon. Besser geht es wahrscheinlich nur mit Delphi, TQuery, alles abfragen und durchsteppen und mitzählen. @geben Sie mir alle Brötchen, die.. Ich kann in der Variante oben durchaus alle nicht vorhanden Brötchen einbinden. Dazu müsste ich eine Tabelle ergänzen, die alle Lückengrößen beinhaltet, die ich prüfen möchte. Also mit einer Tabelle 10 Datensätze und den Werten 1-10 finde ich alle Lücken bis Größe 10, usw. Die Stored Procedures in Paradox sind "Delphi" oder andere Clients. |
AW: Lücken in fortlaufender Nummerierung finden
Zitat:
|
AW: Lücken in fortlaufender Nummerierung finden
Zitat:
Bei Paradox wird es am Einfachsten sein mit dieser Schleife auf leere Ergebnismengen zu Überprüfen. |
AW: Lücken in fortlaufender Nummerierung finden
Zitat:
![]() Das generiert dir eine Reihe von Datensätzen, nach einem bestimmten Muster. Kann man selber bauen (stored procedure) und gibt es auch oftmals fertig. |
AW: Lücken in fortlaufender Nummerierung finden
Das gibt's alles nicht in local sql.
In Postgres generate_series(), in mysql einfach mit variablen in SQL, usw. ah, steht ja in deinem Link :oops: :) |
AW: Lücken in fortlaufender Nummerierung finden
Da hier ja sowieso kein potenter SQL-Server zum qualmen gebracht werden soll, würde ich hier den Heimvorteil der BDE/Paradox-Kombination ausnutzen: Was spricht denn gegen ein sequentiuelles Durchlaufen der Tabelle. Dabei kannst du doch die Lücken direkt erkennen und auflisten. Das hier unbeding mit SQL zu vergewaltigen ist doch gar nicht zielführend.
Delphi-Quellcode:
procedure FindGaps(DataSet: TDataSet; FieldName: string; Target: TStrings; CheckFirst: Boolean);
procedure AddGap(von, bis: Integer); var S: string; begin if von < bis then begin S := Format('%d-%d', [von, bis]); end else begin S := Format('%d', [von]); end; Target.Add(S); end; var fld: TField; id: Integer; nextId: Integer; S: string; begin Target.BeginUpdate; try DataSet.Active := true; if DataSet.IsEmpty then Exit; { DataSet muss nach FieldName sortiert sein } fld := DataSet.FieldByName(FieldName); DataSet.First; if CheckFirst then begin nextId := 1; end else begin nextId := fld.AsInteger; end; repeat id := fld.AsInteger; if nextId < id then begin AddGap(nextId, id - 1); end; nextId := id + 1; DataSet.Next; until DataSet.Eof; finally Target.EndUpdate; end; end; |
AW: Lücken in fortlaufender Nummerierung finden
Genau, der TE wollte zwar SQL, aber Dein Vorschlag finde ich hier auch am sinnvollsten!
|
AW: Lücken in fortlaufender Nummerierung finden
Würde es für Paradox ne SQL-Lösung geben wäre die auch sehr wahrscheinlich schneller als eine in Delphi.
War also keine schlechte Idee nach SQL zu fragen bzw. es mit SQL zu versuchen. |
AW: Lücken in fortlaufender Nummerierung finden
Mann oh mann, ich hätte nicht gedacht, dass dazu SO viele Antworten kommen... Danke erst mal an alle
Dass das Ganze "von Hand" geht(durchgehen nach Uwe's Vorschlag) war mir auch klar, und ist definitiv die übersichtlichste und "flexibelste" Variante, da dort auch größere Lücken auffindbar sind. Ich hatte halt nur auf eine "einfache elegante" Variante per SQL gehofft.... Aber ich habe alles an Antworten bekommen, was man sich so wünschen kann... Werde es mal mit Uwe's "durchgehen" versuchen...wird zwar nicht schnell sein, aber erstmal egal |
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:12 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz