ADS

[Manfred]

Hi,

ich war gerade auf der Tobax Seite und habe ein wenig gestöbert. Dort fiel mein Blick auf den ADS. In der Beschreibung steht jetzt, das der (auch) unter Linux läuft, oder verstehe ich da jetzt was falsch?

Ich blicke überhaupt nicht durch. Hat da wer eine Antwort parat?

PS: Ich habe gerade auf der Seite von Extended Systems nachgelesen, das ist der Fall. Aber heißt das dann für mich, dass ich auf jeden Fall einen Linux Fileserver benutzen kann? Hört sich ganz so an......

[wsoftie]

Hallo Manfred,

habe mir auch die Testversion vom ADS-Server installiert. Wenn ich es richtig verstanden habe, können nur Linux-Programme, die z,B, mit FlagShip übersetzt wurden auf den Server zugreifen. Ein Client für Windows steht meines Wissens nicht zur Verfügung.

Ciao
Werner Petersen

[klammerauf]

Ich stolpere immer mal wieder über diesen, na sagen wir mal nicht ganz taufrischen Beitrag. Und jedesmal stellen sich mir die noch verbliebenen Haare auf.

ADS ist mittlerweile ein Produkt von Sybase, dem Hersteller von iAnywhere und anderen Produkten. Hier ein Link direkt zum Advantage Database Server:
http://www.advantagedatabase.de/web/con ... 4BAD33FF3B

Bei diesem System handelt es sich um ein Client-Server-DBMS. Das bedeutet, dass auf einem Server ADS läuft und mit verschiedenen Clients auf den Server zugegriffen werden kann.

Der ADS-Server läuft unter Linux, Windows oder Novell. Es gibt Clients für Xbase++, Clipper, Delphi, Java, und was weiß ich noch alles unter Windows. Ob es auch für Linux einen Client gibt, weiß ich nicht.

Der Zugriff vom Client auf den Server funktioniert über eine IP-Verbindung, das kann eine Verbindung im lokalen Netzwerk als auch über das Internet sein. Zusätzlich gibt es auch den Local Server, der auch ohne Netzwerk zurechtkommt und auf lokale Laufwerke zugreifen kann.

Der Vorteil von ADS liegt darin, dass nicht mehr viele Clients auf das gleiche DBF-File zugreifen und unter Umständen bei einem Crash den empfindlichen Index in Mitleidenschaft ziehen, sondern dass alle Anfragen zentral vom ADS-Server gehandelt werden. Der kann viel besser entscheiden wer wann zugreifen und z.B. einen Satz sperren darf.

Zusätzlich bietet ADS neben DBF mit NTX/CDX auch noch ein eigenes Datenbankformat namens ADT. Das bietet viel mehr Feldtypen (z.B. Money und Timestamp) und man kann darüber hinaus auch mit SQL-Befehlen arbeiten.

Mehrere Tabellen kann man zu einem so genannten Data Dictionary zusammenfassen. Dabei ist es unerheblich, ob die im Forma DBF oder ADT vorliegen. Mit diesem DD kann mann sehr fein justieren, welcher Benutzer (auch Benutzergruppen) was machen darf. Damit sind dann auch Stored Procedures, vordefinierte Views oder hilfreiche Constraints möglich.

Weitaus besser als die ADSDBE von Alaska gefällt mir AceServer++ von ds-datasoft.de. Da kann man mit sowohl auf ADTs als auch auf die Data Dictionaries zugreifen.

Mit

Code: Alles auswählen

PROCEDURE DBESYS() ; RETURN

kann man gleich alle DBEs von Alaska ausklammern und Speicherplatz sparen. Allerdings ist dann nur noch ein Zugriff auf alle Tabellen objektorientiert möglich. Das bedeutet, dass man alle

Code: Alles auswählen

DBUSEAREA(TRUE,,"TEST.DBF",,TRUE)
TEST->(GoTop())

gegen

Code: Alles auswählen

oServer := OpenAceServer( oSession, "TEST.DBF" )
oServer:GoTop()

austauschen muss. Auf längere Sicht hat das aber den Vorteil, dass man sich nicht mit Workareas rumplagen muss, die man nur mühsam zwischen Modulen weitergeben konnte.

Natürlich wirbt der Hersteller damit, dass ADS viel schneller sei als der herkömmliche Zugriff. Er erwähnt aber nicht, dass die ganze Sicherheit und der Luxus von SQL-Zugriffen zumindest beim ersten Öffnen einer Datenbank einfach Zeit in Anspruch nimmt. Wer also z.B. bei einem Kommandozeilentool nur eine Tabelle durchsuchen will, der ist mit DBFNTX schneller fertig, also mit ADS.

Ich hoffe, das ändert das Bild von ADS, das durch meine beiden Vorposter entstanden ist.

Sebastian

[Manfred]

So,

gerade wurde ich von Sybase angerufen. Sozusagen als Nachbearbeitung der Devcon.

Hm, nachdem ich nun den ADS mehr oder weniger komplett aus meinen Gedanken verdrängt hatte, ist er jetzt natürlich wieder da.

Also fangen wir das Thema nochmals an.

Wie seht ihr das jetzt, nach fast 1 Jahr und der PostgreSql Zukunft mit Xbase++?

Im Moment wüßte ich nicht einmal, was ich an Xbase++ Voraussetzung mitbringen muß um damit arbeiten zu können.

[klammerauf]

Hallo Manfred,

sollte die Frage nicht eher lauten, wie seht ihr die Zukunft von Xbase++?

Und meinst du die DevCon in Kassel im La Strada?

Ich denke, ADS ist zuverlässig, schnell genug, sehr flexibel und durch Sybase ziemlich zukunftssicher. Dann wird ADS ja nicht nur von Xbase++ unterstützt (wohl eher die Minderheit), sondern von zahlreichen anderen Programmiersprachen, die die ganze Sache lebendig halten.

Wichtig und wertvoll finde ich die Möglichkeit, SQL-Befehle und Xbase-Befehle wie Skip(), Goto(), usw. miteinander mischen zu können. Das funktioniert auch mit dem ADS-eigenen Datenbankformat ADT, das um Längen besser ist als DBF/NTX/CDX.

Mag sein, dass die Voraussetzungen eine kleine Hürde sind. Denn (um auf deine Frage einzugehen), folgendes wird benötigt:

- mind. der ADS Client mit dem enthaltenen Local Server
- besser einen Windows-, Novell- oder Linux-Server für den Remote Server
- ADSDBE (in Prof. Subscription enthalten, nicht meine Empfehlung) oder
- AdsClass++ von DS-Datasoft (definitiv meine Empfehlung, geht aber nicht mit Workareas sondern nur noch mit Objekten, also kaum für vorhandenen Sourcecode zu gebrauchen)

Die Leute von Extended Systems in Herrenberg habens meiner Meinung nach auch richtig drauf, so dass eigentlich keine Frage zu ADS unbeantwortet bleiben sollte, wenn man dort einfach mal anruft.

Damit mein letzter Beitrag zu diesem Thema abgerundet wird, hier noch die offizielle Spezifikation zu ADS von Sybase:

SPECIFICATIONS

Server Operating System
------------------------------
Novell NetWare 5.x or greater (IP, IPX)
MicrosoftWindows x86 (IP, IPX)
MicrosoftWindows x86_64 (IP)
Linux x86, x86_64 (IP)

Client Operating Systems
------------------------------
MicrosoftWindows
Linux
Any operating system that supports the Java Runtime Environment 1.3 or greate

DEVELOPMENT ENVIRONMENTS
------------------------------
• Borland Delphi (via native TDataSet descendant components, OLE DB Provider for ADO, ODBC
Driver, or API)
• C++Builder (via native components, OLE DB Provider for ADO, ODBC Driver, or API)
• Visual Studio.NET (via .NET Data Provider)
• Borland Delphi for .NET (via .NET Data Provider or native TDataSet descendant components)
• JBuilder (via JDBC)
• Sun ONE Studio (via JDBC)
• Visual Age for Java (via JDBC)
• Visual Basic (via OLE DB Provider for ADO, ODBC Driver, or API)
• Access (via OLE DB Provider for ADO, ODBC Driver, or API)
• Visual C++ (via OLE DB Provider for ADO, ODBC Driver, or API)
• Visual FoxPro (via OLE DB Provider for ADO, ODBC Driver, or API)
• Perl (via DBI driver)
• PHP (via PHP Extension)
• Visual Objects (via RDD, OLE DB Provider for ADO, ODBC Driver, or API)
• CA-Clipper (via RDD)
• any development environment that can access ADO/OLE DB, ADO.NET, an ODBC driver, a JDBC driver,
or can make a call into a Windows DLL or Linux shared object (via API)

Language Support
------------------------------
support for most of the ANSI SOL-92 standard
ANSI PSM 2003 scripting support

Supported File Formats
------------------------------
Advantage proprietary database (ADT tables, ADI index files, ADM memo files)
FoxPro-compatible (DBF tables, CDX index files, FPT memo files)
CA-Clipper compatible (DBF tables, NTX index files, DBT memo files)
Visual FoxPro-compatible (DBF tables, CDX index files, FPT memo files)

[brandelh]

Hallo Manfred,

die Frage ist, ob du mehr brauchst (Datenmenge, Anzahl User, Systemsicherheit, Objektorientierter Zugriff ...) als die DBF/FOX-DBE leisten können.

Jeder DB-Server wird mehr oder weniger (laut einer Antwort die ich erhalten habe ist der ADS local Server sehr wenig Aufwand) Änderungen am Quellcode nach sich ziehen und auch ein anderes Vorgehen beim Anlegen bzw. Verwalten der Daten auf dem Datenlaufwerk.

Die Datensicherheit und höhere Performance resultiert zum Teil ja genau daraus, dass dein Programm nicht einfach mal die Indexe löschen darf, die ein anderer gerade braucht.

Ich persönlich musste mit mit SQLExpress Zugriff auf Access Daten beschäftigen und habe dabei gleich mal einige Tests gegen MySQL und MsSQL Server gefahren. Bei meinen Datenmengen und gleichzeitigen Anwendern bin ich zu dem Schluss gekommen, dass sich das für mich nicht lohnt.

Sicher auch deswegen, da meine Programme auf einem lokalen Terminalserver Fileserver Verbund betrieben werden und somit die Abbrüche die auf den WAN Leitungen entstehen keine offenen Dateien killen. Außerdem habe ich von der Programmierung her meist keine offenen Dateien, sondern die meisten meiner Programme verhalten sich wie z.B. Excel bei einer offenen Arbeitsmappe.

Tom z.B. hat schon öfter geschrieben, dass ihre Anwendung ohne ADS (oder einem anderen Datenbankserver) gar nicht laufen würde.

Ich rate dir dich zu fragen ob du die Datenmenge oder Sicherheitsprobleme hast die einen Umstieg nötig machen.

Wenn ja, dann sieh dir mal ADS (gibt es da Testserver ?) und PostGresSQL an.
Welchen Server möchtest du selbst verwalten bzw. deinen Kunden erklären ?
Sind deine Kunden bereit die Lizenzgebühren für die ADS zu zahlen ?
Für den Zugriff kannst du dann entweder die ADSDBE (falls vorhanden) oder SQLExpress (Testversion) verwenden. Sicherlich wird sich bei der in Xbase++ native eingebauten Version einiges ändern, aber die Server als solche musst du verwalten.

Solltest du die Probleme noch nicht haben, freu dich über die einfachen DBF/FOX-DBE Treiber

[Manfred]

Hubert Du sprichst mir mal wieder aus der Seele.

Der Kunde muß den bezahlen. Das ist der Punkt, an dem es sehr wahrscheinlich scheitern wird.

Was interessant ist, ist der Zugriff über ein VPN. Da ist es mit einfachen DBF Dateien nicht getan. Allerdings schwirrt mir da schon evtl. eine Lösung mit PostgreSql durch den Kopf, die ich sicherlich in diesem Jahr noch ausprobieren werde.

[brandelh]

Hi,

gerade bei Fernzugriffen solltest du auch den Terminalserver in Betracht ziehen, da ist dein Programm zentral auf dem Terminalserver installiert, eventuell auch gleich die Daten dazu (falls du nur einen brauchst). Alles läuft lokal und das einzige was über das WAN geht sind die geänderten Bildschirminhalte (stark komprimiert). Das ist sehr sicher und auch schnell.

Beim Drucken muss natürlich mehr über die Leitung und man muss den lokalen (oder einen anderen Netzwerkdrucker) als Netzwerkdrucker einrichten und dem Terminalserver als Ziel freischalten. Dafür gibt es wohl neuerdings ThinPrint ... genaueres weiß ich auch nicht, da dafür unser EDV-Dienstleister zuständig ist

Auf jeden Fall braucht keiner der Anwender selbst Zugriff auf des Datenverzeichnis, da das ja nur dem Terminalserver zugeordnet ist.

[Manfred]

Hubert,

datt war jetzt nicht so gut.

Einen Terminalserver werde ich auch schon aus Kostengründen keinem anbieten können.
Aber das Thema ist absolut nicht im Gespräch, weil es immer nur um Linux mit Samba geht. Und da ist mit Terminalservern nix zu machen.

[brandelh]

Hallo Manfred,

datt war jetzt nicht so gut.

das siehst du völlig falsch, ernst gemeinte Vorschläge sind immer gut,
ob sie auf deinen Fall passen musst du dann selbst entscheiden

Einen Terminalserver werde ich auch schon aus Kostengründen keinem anbieten können.

das ist so nicht richtig, falls deine Kunden einen nicht zu alten Windowsserver haben,
haben sie auch einen Terminalserver mit bezahlt.
Bei den Zugriffslizenzen bin ich jetzt aber etwas überfragt

Aber das Thema ist absolut nicht im Gespräch, weil es immer nur um Linux mit Samba geht. Und da ist mit Terminalservern nix zu machen.

Jetzt wird es natürlich klar, warum der Terminalserver in deinem Falle nicht geht, aber dennoch ist er ein sinnvoller Vorschlag für andere

In einem VPN kann man natürlich bis zu einer gewissen User-Zahl mit DBF/FOX-DBE arbeiten, insbesondere wenn man die Dateien nicht Feld bzw. Satzweise speichert, sondern wie ich immer alles in Arrays einlesen, bearbeiten und dann auf einmal speichern. Mit DSL geht es wohl auch recht flott, aber jede Störung kann Fehler in den Indexdateien und oder den Datendateien verursachen, die nicht sofort oder gar nicht auffallen müssen.

In deinem Beispiel ist es am sinnvollsten mit Datenbankservern zu arbeiten. Ich habe das mit SQLexpress getan, wobei Phil eine Klasse geschrieben hatte um ohne ODBC direkt auf PostGreSQL zuzugreifen (wesentlich schneller soll das gewesen sein).

Auf die direkte Integration bin ich wirklich gespannt.

[Manfred]

Hi Hubert,

das war auch nicht gegen Dich geschickt. Ich wollte damit nur mitteilen, das das die Teufel Belzebub Taktik wäre. Aber ich vergaß, dass ein Terminalserver bei einem Windowsserver dabei ist. Aber da keiner meiner Kunden einen Windowsserver hat, ist das auch außerhalb der Überlegungen. Aber das hätten wir ja dann jetzt geklärt.

[andreas]

Hallo Manfred,

in deinem Fall würde ich den PostgreSql bevorzugen:
1. ist schon bei Linux dabei.
2. Du kannst bald direkt mit XBase++ darauf zugreifen (Vortrag von Steffen am 22.05.2008, danach sollte die DBE für alle aktiven Kunden freigegeben werden).
Oder du nimmst wirklich das Programm von Phil, was aber wahrscheinlich keiner mehr pflegen wird, wie es zur Zeit aussieht.

[Jan]

Hallo Andreas,

Vortrag von Steffen am 22.05.2008, danach sollte die DBE für alle aktiven Kunden freigegeben werden

Wenn Du Dich da man nicht vertust. Lt. Aussage Alaska zu der PostreSQL-Konferenz nicht unbedingt (für mich z. B. nicht mit der Foundation Subscription). Da steht nämlich in den Questions and Answers, vorletzter Eintrag:

We plan to include the PostgreSQL DatabaseEngine in the Professional

Also nicht für jeden mit aktiver Subscription, sondern vermutlich nur für aktive Professional Subscriptions.

Jan

[Rudolf]

Hallo,
habe schon einiges mit SQL (SQLEXPRESS) gemacht, ist aber von der Logik her komplett anders zu programmieren als mit den DBF Tabellen. Wie Alaska es mit Arctica beschreibt, kann ich es mir nicht vorstellen das sowas auch praktisch funktioniert. Wenn z.B. eine Tabelle mit einer Million Datensätze geöffnet wird und in einem Browser bearbeitet werden soll, muss die ganze Tabelle bei SQL eingelesen werden, und das kann ziemlich dauern. Ich habe z.B. überall eine inkrementelle Suche in den Browsern, die kann ich dann vergessen, es würde zu lange dauern bei jedem Tastendruck das Select auszuführen. Von den angeblichen Geschwindigkeitsvorteilen habe ich nichts gemerkt, im Gegenteil. Viele Dinge sind komplexer zu programmieren geworden und vieles ist auf Grund der mengenorientierten Abfragen einfach langsamer. Mit den normalen DBF/CDX Dateien bin ich überall viel schneller. Also so schön sich das Ganze anhört, ich habe da erhebliche Zweifel dass mit nur einer Zeile Programmänderung auf SQL umgestellt werden kann.
Grüsse
Rudolf

[Jan]

Moin Rudolf,

genau das ist ja das Problem. Das Kunden meinen: SQL ist das einzig Wahre. Was ja so nicht unbedingt stimmt. Natürlich hat SQL Vorteile. Aber nicht immer, und nicht in jeder Situation.

Das Ganze erinnert mich an ein Erlebniss in meiner alten Firma. Eines Tages kam mein Chef an, sein Sohn hätte ihm gesagt, wir sollten auf SAP R/3 umsteigen. Das wär ja so genial. Nun, wir hatten damals vor ca. 12 Jahren insgesamt 8 EDV-Arbeitsplätze. Klar, R/3 mag toll sein (obwohl ich eher andere Sachen darüber gehört habe). Aber nicht in der damaligen Situation.

Und genau das ist ja auch mit SQL. Klar ist das toll. Aber ich bin mir sicher, daß eines Tages Kunden meines Kunden ankommen werden und schreien: SQL muß her! Ob das für dieses spezielle Projekt Sinn macht oder nicht. Die wollen das einfach haben. Und von daher könnte ich mir vorstellen, daß die neue Geschichte von Alaska mit PostgreSQL sehr gut wäre. Denn dann kann ich den existierenden Code weiternutzen. Und nur für diese paar Übereifrigen die entsprechende Codezeile einfügen, und alles ist erledigt. Spart mir eine Menge Arbeit und Doppelentwicklungen.

Allerdings bin ich mal gespannt, wie die Perfomance sein wird. Denn mit SQL kann man ganz sicher mit den richtigen Indizee und Queries sehr schnell sein. Mit den falschen aber auch das ganze System enorm in die Knie zwingen. Da bin ich auf die interne Umsetzung der dbf-Funktionen auf SQL-Format gespannt.

Jan

[Rudolf]

Hallo Jan,
ich sehe es auch eher als Argument zur Beruhigung meiner Kunden. Ich habe in letzter Zeit bei manchen Projekten den Kunden über die Vor- und Nachteile von SQL informiert, habe dann immer auf SQL verzichten können. Und mir Arctica habe ich zumindest weniger Arbeit bei der Umstellung und kann jederzeit wieder zurück auf die DBF wenn es nicht klappt.
Grüsse
Rudolf

[Tom]

Ich bin wirklich gespannt, wie eine DBE arbeiten soll und wird (und mit welcher Performance), die einer datensatzorientiert (!) arbeitenden Applikation SQL unterjubelt. Ich nehme an, dass in der Frühphase mit sehr vielen Single-Record-Cursors (Current Record Set) gearbeitet werden wird, also die irgendwie SQL-Statements generiert werden, die der App den Eindruck vermitteln, datensatzorientiert zu arbeiten. Anders kann ich mir die Umstellung auf SQL "mit nur wenigen Zeilen Programmcode" derzeit nicht vorstellen. Aber ich lasse mich gerne überraschen.

Der Vorteil der ADS besteht darin, dass sie so gut wie wartungsfrei ist, sich in Minutenschnelle installieren lässt und unter quasi allen vorstellbaren Bedingungen völlig problemlos arbeitet. Aus Sicht unseres Supports stehen trotzdem die einzelnen Tabellen in Wartungsfällen zur Verfügung. Denen ist in dieser Situation relativ egal, ob die ADS-Version oder die Normalversion (DBFNTX) installiert ist, weil das, die Datenhaltung betreffend, keine Rolle spielt. Zudem sind Datensicherheit und Performance deutlich besser als ohne ADS. Es ist außerdem stabiler. Datenprobleme sind mit ADS so gut wie unbekannt.

Mit SQL ist die Datenbank ein gekapselter Monolith. Wir haben in unserer Mehrmandantenversion, die sich bis auf Dateiebene nach Kundenwünschen gestalten lässt (der Kunde kann also entscheiden, welche Daten zentral gehalten werden und welche mandantenabhängig sind), ein Modell eingesetzt, das sich über Suchpfade und einige Tricksereien nur wenig von der Nicht-Mehrmandantenversion unterscheidet. Bei SQL müsste hier auf Datensatzebene (Felder zur Identifikation des Mandanten) oder über die Dateinamen Identifikation betrieben werden. Zudem haben wir enorm viele sehr kleine Tabellen, der Datenbestand und die Anzahl der Tabellen fluktuieren stark. Einige Performancetests unter Einsatz von SQLExpress haben gezeigt, dass man hier mit einem dateibasierten Datenkonzept spürbar besser unterwegs ist. Ein SQL-Server muss gewartet und bezogen auf Benutzer und Rollen intensiv konfiguriert werden. Mal eben so eine einzelne Datei austauschen (z.B. aus der Datensicherung holen) ist hier etwas problematischer. Stored Procedures, die ja nach meinen Informationen mit Artica eine große Rolle spielen sollen, müssen gesondert auf dem SQL-Server installiert werden, und wenn da ein SQL-Admin herumpopelt, stirbt alles. Ich bin also vergleichsweise skeptisch, sehe - außer bei großen Datenbeständen, vorzugsweise in einzelnen Tabellen - im Moment nicht wirklich die Vorteile. Aber wir werden es tun, und sei es nur, um auch noch die letzte Frage beim Vorführtermin nickend beantworten zu können. Im Hinblick auf unsere Mobilanwendungen und andere Synchronisations-/Replikationsaufgaben sehe ich allerdings tatsächlich starke Vorteile.

[Rolf Ramacher]

Ich denke mal SQL lohnt sich nur bei größeren Datenmenge und Usern.
Und wie Tom schon erwähnte - es muß gepflegt werden. Entweder du selber, oder der Kunde ist so versiehrt das er dies kann.

Hierbei werde ich wohl verschont bleiben, da meine Kunden "Einzelkämpfer" sind und nur eine Handvoll ein netzwerk einsetzt.

Ich werden höchstens später mal von dbase3 Datenbanken auf Foxpro-Datenbanken umsteigen.

[Alfred]

Hallo Rolf,

was spräche denn für die Foxpro-Datenbanken.

Ich habe es bislang tunlichst vermieden auf die neue Version(also die nach
2.6) zu gehen.

Gruß
Alfred

[Jan]

Hallo Alfred,

ich setze selber die Foxpro-Version der Datenbanken ein. Inkl. der Indizee, also als FOXCDX.

Die Vorteile sind für mich:
- Die Datenbank hat das Sequenze-Feld zum datenbankgesteuerten (!) Hochzählen. Für mich wesentlich sicherer als ein programmgesteuertes Hochzählen in Netzwerkumgebung.
- Es lassen sich Binär-Daten speichern. nutze ich hauptsächlich für Bilder. OK, ich habe mich bekehren lassen müssen, daß das auch so geht. Aber für mich war das der einfachere Weg.
- Die Memo-Verwaltung ist wesentlich effizienter als bei dbf-Formaten.
- Die Indizee lassen TAGs zu. Ich arbeite also normalerweise mit einer Datenbank DummyName.dbf. Und dazu gibt es genau einen Index DummyName.cdx. Das ist für mich schlichtweg gewaltig übersichtlicher.

Jan

[Manfred]

Hi Jan,

um die CDX und die Tags nutzen zu können, bedarf es aber nicht automatisch des FoxCDX Treibers. Ich nutze auch die CDX, habe aber den Foxtreiber nicht mit drin, sondern arbeite mit DBFCDX.

Und das Hochzählen der ID im Netzwerk klappt m.E. bei mir auch recht gut und ich denke mal, dass ich da eine stabile Lösung gefunden habe.

[Jan]

Moin Manfred,

ja, DBFCDX habe ich früher auch benutzt. Aber wegen des Sequence-Feldes und der Möglichkeit der Bilder in den Feldern bin ich dann Ende letzten Jahres auf FOXCDX umgestiegen. Das mit dem Memo-Feld hat mich ehrlich gesagt nicht sonderlich interessiert.

Wegen des Hochzählens: Schön, wenn Du da eine stabile Lösung gefunden hast. Und ich wünsche Dir, daß es das auch ist. Aber ich hatte einfach Angst, daß 2 User genau gleichzeit auf die Taste hauen, und dann eine Nummer doppelt drin steht. Und genau das sollte mit dem Sequence-Feld nicht mehr passieren. Außerdem brauch ich mich dann nicht mehr kümmern. Keinen Code schreiben zum sicheren Hochzählen. Weil das in der Datenbank selber passiert. Man kann das auch Faulheit nennen, wenn man will . Ich nenn es Sicherheitsbewußtsein Und intelligentes (!) Ausnutzen vorhandener Lösungen

Jan

[Manfred]

Jan,

ich habe Deinen Tritt schon verstanden.

Aber wie war das mit der Anpassung von Strukturen, oder wo war das, dass der Zähler immer nur 4 schreibt?

Aber mach watte wilz.

[Jan]

Aber mach watte wilz.

Du glaubst doch nicht im Ernst, daß ich mich von DIR abhalten lasse NICHT VON DIR!!!

dass der Zähler immer nur 4 schreibt?

Ja, das stimmt. Leider. Aber da gibt es immerhion einen PDR drüber, ich denke also mal, das wird demnächst gelöst. Und in der Zwischenzeit mache ich das mit 1 Zeile Code, die in der Strukturänderung ganz vorne an steht. So oft habe ich meine Datenbankstrukturen dann ja auch wieder nicht zu ändern. Zum Glück.

Jan

[Rolf Ramacher]

So wie ich das gesehen habe, ist die Verwaltung von Foxpro-Datenbanken unter Xbase erweitert worden. Was die Anzahl der Felder betrifft z.B.

Ich habe das auch schon mal getestet. Man braucht ja nur die bisherigen
DBF zu nehmen mit dme DBFCDX und als neue mit FOXCDX zu schreiben.

Oder sehe ich das falsch. Mit dbu bzw. mit meinem dbedit bekomme ich dann diese Datenbanken nicht mehr auf. Aber mit meinem dbedit32

Ich weiß allerdings nicht welche Version FOXCDX hat