Inoffizielles deutsches Xbase-Forum

Kann man eigentlich (DD ist eingebunden) über normale DBF einen automatischen Zähler für eine ID einbauen, der vom ADS dann auch verwaltet wird, oder geht das nur mit ADT oder händisch?

Manfred,

solange Du im ADS mit der FOXCDX arbeitest geht das. Feldtyp "S".

Jan

Jan hat geschrieben: ↑Mo, 01. Jun 2020 9:05 solange Du im ADS mit der FOXCDX arbeitest geht das. Feldtyp "S".

Äh, die FOXCDX hat doch erstmal nichts mit dem ADS zu tun, oder?
Das entscheidende ist, dass es den Datentyp geben muß. Und wenn im DataDictionary bzw. in den darin befindlichen Tabellen der TableType "VFP" (=Visual Fox Pro) oder "ADT" ausgewählt ist, geht das. Der zugehörige Datentyp ist "autoinc".

Uli,

es geht doch hier um dbf im ADS, nicht um ADT. Darum fragt Manfred ja explizit. Und wenn er FOXCDX in den ADS einbindet, kann der das machen wie ich beschrieben hatte. Das hat ja nicht direkt etwas mit ADS zu tun.

Jan

Nein.

Nein was?

Nein, hat nix mit ADS zum Tun. Fox kann Autoinc implizit, mit oder ohne ADS.

kann man das denn auch nachträglich ändern? Also wenn ich jetzt die FOXCDX DBF in ein DD gepackt habe, über SQL befüttern möchte und deshalb die bisher selbstgebaute Hochzählroutine nicht mehr nutzen kann/möchte. Was stelle ich da ein? Ich sehe derzeit nur GUID als Data Type. Aber kommt da nicht nur einfach ein "Zufallsstring" rein? Und wenn, wo trage ich dann den Startwert ein, weil der ja schon im Laufe der Zeit hochgezählt wurde und somit nicht mehr bei 1 anfangen darf.

Tom hat geschrieben: ↑Mo, 01. Jun 2020 13:40 Nein, hat nix mit ADS zum Tun. Fox kann Autoinc implizit, mit oder ohne ADS.

Ich meine, Du irrst Dich da. Fox kann Autoinc nicht, wohl aber Visual FoxPro.
Zumindest muß man im Data Dictionary beim Anlegen einer Tabelle als Tabellentyp VFP angeben. Bei CDX gibt es den Feldtypen "Autoinc" nicht.

Manfred hat geschrieben: ↑Mo, 01. Jun 2020 13:46 kann man das denn auch nachträglich ändern? Also wenn ich jetzt die FOXCDX DBF in ein DD gepackt habe, ...

Was für ein Tabellentyp wird denn im ARC bei diesen Tabellen angezeigt?

Uli,

ich arbeite fast ausschließlich mit FOXCDX. Und in einigen Anwendungen mit Feldtyp "S". Das ist sicher kein ganz so stabiler Autoinkrement wie das in SQL z. B. gemacht wird. Einfach weil der Zähler durch die DBE gesteuert wird, und man notfalls daran vorbei arbeiten kann. Aber es ist letztendlich doch ein Autoinkrement, wenn man es richtig macht. Und ob dann die dbf im ADS liegt oder nicht ist egal.

Jan

Hallo Jan,

ich vermute, dass die FOXCDX nicht nur das Foxbase-Datenformat sondern auch Visual Foxbase Pro Format kann.
Aber Du hast schon die Tabelle im DataDictionary, oder? Bitte schau darin nach, was im Data Architekten für ein Datentyp bei diesem Feld angezeigt wird und was für ein Datentyp für die Tabelle angezeigt wird. Das interessiert mich sehr.

Uli

mich auch, zumal ich mit meiner Zwischenlösung heute kräftig auf die Schnauze gefallen bin.
Ich führe derzeit eine Extratabelle, in der alle ID gespeichert werden. Diese öffne ich immer für einen kurzen Moment exclusiv, schreibe dann die neue Nummer rein und schließe sie wieder. Das habe ich jetzt mit einem SQL Befehl nachgebaut. Aber der ADS cached die DBF jetzt, weil ich die über SQL anspreche und verhindert somit, das andere die exclusiv öffnen können. Wattn Mist auch.

Exclusiv ist bei SQL keine gute Lösung . Mit Hilfe von Joachim habe ich dafür eine seit vermutlich 10 Jahren 100% funktionierende Lösung! Bei Interesse suche ich die raus und veröffentliche sie hier.

Uli,
LESEN.....

Manfred hat geschrieben: ↑Di, 02. Jun 2020 13:10...LESEN.....

Warum schreist Du so?
Und was soll ich lesen, falls Du das meinst?

weil ich schrieb, das ich es bisher exclusiv geöffnet habe.
Aber jetzt sehe ich ein, das Du den Satz etwas falsch betont gelesen haben wirst und deshalb meintest, ich würde es mit SQL exclusiv versuchen. Aber ich wußte gar nicht, das sowas auch geht.

Manfred hat geschrieben: ↑Di, 02. Jun 2020 13:17... Aber jetzt sehe ich ein, das Du den Satz etwas falsch betont gelesen haben wirst und deshalb meintest, ich würde es mit SQL exclusiv versuchen. ...

Ach so. Aber ohne exclusiv muß man einigen Aufwand betreiben, damit es nicht im Multi-User-Betrieb kracht und die gleiche Id mehrfach vergeben wird.

deshalb ja auch meine Frage hier mit dem AutoIncrement. Ist natürlich immer besser sowas dem Server zu überlassen. Also habe ich es erstmal wieder rückgängig gemacht und lasse mir eine bessere Lösung einfallen.

wenn man es mit einem SQL macht, muss man eine Transaction drumrumsetzen, ist dann wie exclusiv ausgeführt.
Hier als Funktion

create function NextId() returns integer
begin
declare id integer;
Begin;
update <table> set id = id +1 where ...;
id = (select id from <table> where ... );
commit;
return @id;
end;

Kann man dann so ansprechen
insert into <table>(id, ....)
values (NextID(), ....);

legt man die dann im Architekten ab unter Functions, oder wie war das gemeint?

Das SQL einmalig im ARC ausführen, es wird die Function erzeugt:
Danach kannst du wie beschrieben darauf zugreifen.

Wenn es nicht um numerische IDs geht, würde ich grundsätzlich dringend empfehlen, nicht (mehr) mit Zählern zu arbeiten, sondern mit UIDs/UUIDs. Das sind automatisch generierte, ein-eindeutige (bei UUIDs sogar weltweit eindeutige!), zeichenbasierte IDs, die man in Xbase++ mit einem simplen Aufruf von UuidToChar(UuidCreate()) erzeugen lassen kann. Da spielt dann auch keine Rolle mehr, wo irgendein Zähler stand oder so. Aber das ist wirklich nur für das interne Matching geeignet. Bei Auftrags- und Kundennummern und solchem Zeug muss man natürlich anders arbeiten.

Marcus Herz hat geschrieben: ↑Di, 02. Jun 2020 13:30 wenn man es mit einem SQL macht, muss man eine Transaction drumrumsetzen, ist dann wie exclusiv ausgeführt.
Hier als Funktion ...

Marcus, aber dadurch verhinderst Du nicht, dass in einer Multiuser-Umgebung die gleiche Id mehrfach zurückgegeben werden kann!

Hi Tom,
ich nutze die wirklich nur um Verknüpfungen zu erstellen zwischen Tabellen. Irgendwie kann man sowas m.E. besser mit normalem Blick erkennen, wenn man mal was nachschauen und vergleichen muß. Aber vielleicht sollte ich mein bisherige Konzept wirklich mal überdenken. Änderbar wäre das ja sofort. Man muß nur den Feldtyp von numerisch auf Charakter umstellen, breiter machen evtl. und dann sagen:"Ab jetzt nur noch UID". Die alten Nummern können ja weiterhin bestehen bleiben. Hätte den Vorteil, das man keine gedöns herum mehr hat mit der Verwaltung der Nummern etc. Hm, ist vielleicht doch keine so schlechte Idee