Moin,
ansich hatte ich ja vor, die Daten bei meinem Kunden nach der Konvertierung von DBFNTX nach FOXCDX auch als FOXCDX in das DataDictionary des ADS zu schieben.
Was wäre der Vorteil, wenn ich das nicht mache, sondern als ADSADT in den ADS schiebe? Mal abgesehen davon, das ich dann nicht mehr ohne den ADS darauf zugreifen kann, wenn die Sache schief gehen sollte? Bei FOXCDX könnte ich mir die Dateien alle wieder zurück holen, neu indizieren, und dann geht es mit der FOXDBE wieder normal weiter.
Jan
FOXCDX vs. ADSADT
Moderator: Moderatoren
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
FOXCDX vs. ADSADT
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- nightcrawler
- 1000 working lines a day
- Beiträge: 653
- Registriert: Di, 24. Apr 2012 16:33
- Wohnort: 72184 Weitingen
- Hat sich bedankt: 3 Mal
- Danksagung erhalten: 96 Mal
- Kontaktdaten:
Re: FOXCDX vs. ADSADT
ADT bietet zusätzliche Datentypen (zB Autoinc, timestamp, modtime, ...), ein automatisches Recycling gelöschter Datensätze, kleinere und schnellere Binärindexe, Referenzintegritäten in der Datenbank, echte NULL Werte, eindeutige Index (unique, nicht distinct), ... hier gibt's eine Übersicht: http://devzone.advantagedatabase.com/dz ... format.htm
- Jan
- Marvin
- Beiträge: 14659
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: FOXCDX vs. ADSADT
Hallo Joachim,
Danke für die Antwort und den Link.
Aber wenn ich mir die Dokus ansehe, dann könnte ich auch in böse Fallen laufen: NULL statt leer, keine leeren Datumsfelder, usw. Wenn ich da nicht aufpasse und eventuell meine Logik anpasse, wäre es vermutlich doch besser, bei FOXCDX zu bleiben? Bei mehreren hunderte Codezeilen könnte mir da was durchgehen ...
Jan
Danke für die Antwort und den Link.
Aber wenn ich mir die Dokus ansehe, dann könnte ich auch in böse Fallen laufen: NULL statt leer, keine leeren Datumsfelder, usw. Wenn ich da nicht aufpasse und eventuell meine Logik anpasse, wäre es vermutlich doch besser, bei FOXCDX zu bleiben? Bei mehreren hunderte Codezeilen könnte mir da was durchgehen ...
Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: FOXCDX vs. ADSADT
Hallo Jan,
grundsätzlich muß man sagen, dass man bei SQL-Tabellen sich an solche Dinge wie NULL-Werte, Behandlung von NULL-Werten in Ausdrucken etc. gewöhnen muß. Ein weiteres Problem ist dabei, dass die ADSDBE nach meinem Wissensstand damit nicht immer korrekt umgeht. Deshalb würde ich auf ADT-Tabellen frühestens in einem zweiten Schritt umstellen.
Deshalb würde ich zunächst bei FOXCDX bleiben auch wenn damit solche Dinge wie referentielle Integritäten oder Trigger nicht gehen sollten.
Uli
grundsätzlich muß man sagen, dass man bei SQL-Tabellen sich an solche Dinge wie NULL-Werte, Behandlung von NULL-Werten in Ausdrucken etc. gewöhnen muß. Ein weiteres Problem ist dabei, dass die ADSDBE nach meinem Wissensstand damit nicht immer korrekt umgeht. Deshalb würde ich auf ADT-Tabellen frühestens in einem zweiten Schritt umstellen.
Deshalb würde ich zunächst bei FOXCDX bleiben auch wenn damit solche Dinge wie referentielle Integritäten oder Trigger nicht gehen sollten.
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück