Inoffizielles deutsches Xbase-Forum

Hey Leute,

ich brauche ein wenig Unterstützung...

Ich hab jetzt schon einiges über ADS gelesen und mein Eindruck ist bisher ein recht guter. Unsere Struktur für XBase++ sind zurzeit DBF-Tabellen auf einem Netzlaufwerk. Wenn ein Client sich anmeldet greift er auf diese zu. Nachteil (meiner Meinung nach): wenn zugegriffen wird, liegt eine lokale Kopie der Daten auf dem Client-Gerät und schreibt diese (bei Bedarf) zurück. Soweit richtig?

Sollte jetzt eine Verbindung abreißen (wir haben einen Netztunnel von Standort A nach Standort B) zwischen den Standorten, dann gibt es Probleme von kaputten Indexen oder ähnlichem. Wenn ich es richtig verstanden habe, müsste der ADS dieses verhindern, oder?

Toll wäre es nämlich, ADS ähnlich zu SQL zu benutzen ohne den angenehmen Aufbau von DBF missen zu müssen. Nur jetzt das Problem: ich gehe davon aus, dass es richtig ist, erstmal die Demo von SAP herunterzuladen. Anschließend muss man das Ding installieren und konfigurieren, nur steige ich hier überhaupt nicht durch.

Kann mir jemand erklären, wie ich den ADS lokal nutze (localhost erstmal) um die Verbindung zu testen?#

Ich wäre euch sehr verbunden!!

Danke schonmal,
LG unicorn

Hallo Jannik,

ich glaube, Du gehst da von falschen Voraussetzungen aus. Wenn Du den ADS auf den Server legst, und die dbf da reinbaust, dann greifst Du auf die dbf zu wie gewohnt. Da wird keine lokale Kopie beim Arbeiten erstellt.

Und Du greifst auf die Daten zu wie bislang. Extra ist nur, das Du vorher eine Connection zu dem ADS und dem DataDictionary aufbauen mußt, in dem die dbf liegen (ich nutze den ADS mit allen Sperrmechanismen gegen Zugriff auf die dbf außerhalb des ADS, da gibt es verschiedene Einstellmöglichkeiten).

Jan

Hallo Jan,

was habe ich dann falsch verstanden?
Wenn ich den ADS benutze, handelt der doch die Zugriffe, richtig? Der ADS wäre dann als Server installiert und hat die DBFs als Tabellen im Hintergrund. Auch wird dabei keine lokale Kopie erstellt, was beim "normalen", also direkten Zugriff auf die DBF jedoch der Fall wäre.

Oder bin ich hier auf einem völlig falschen Dampfer? Wenn ja, klär mich bitte auf!

LG unicorn

Jan hat geschrieben: ↑Mi, 22. Nov 2017 10:41 Wenn Du den ADS auf den Server legst, und die dbf da reinbaust, dann greifst Du auf die dbf zu wie gewohnt. Da wird keine lokale Kopie beim Arbeiten erstellt.

JAN meine mit "zugreifen wie gewohnt" sicher die Syntax der Xbase++ Befehle.

Was anders läuft ist wie er auch erwähnt, dass du einen Connect zum ADS Server herstellen musst.
Die DBF liegt auf dem physikalischen Server und wird vom ADS (Software) Server verwaltet.

Lokal liegen keine Daten, sondern die ADSDBE (vermute ich mal) routet das weiter und nur die Xbase++ Befehle entsprechen denen wie bei DBFNTX etc.

Wenn man den ADS lokal testen will, kann man entweder einen ADS Server auf der lokalen Maschine anlegen (so mache ich das zum Testen mit MySQL) - logischer Serverbetrieb,
oder man nutzt die ADS.DLL - soweit ich mal gelesen habe wird dann die DBF lokal vorgehalten, also auch physisch wie bei DBFNXT.

Hallo Jannik !

Auch wird dabei keine lokale Kopie erstellt, was beim "normalen", also direkten Zugriff auf die DBF jedoch der Fall wäre.

Wer erstellt bei einem normalen Zugriff lokal ein Kopie?
- Xbase++
- Dein Programm
- ...

Je nach Einstellung von Server und Client und Art des Betriebssystems cached das OS unter Umständen lokal.
Das ist von $MS um Office zu beschleunigen; jedoch bringt es gravierende Nachteile für Datei-bassierte Datenbanken mit DBFs wie Xbase++, FoxPro, Clipper/Harbour, usw. aber auch für Access usw.

brandelh hat geschrieben: ↑Mi, 22. Nov 2017 11:23 Wenn man den ADS lokal testen will, kann man entweder einen ADS Server auf der lokalen Maschine anlegen (so mache ich das zum Testen mit MySQL) - logischer Serverbetrieb

Hallo Hubert,

das ist genau das, was ich testen möchte.

Jedoch habe ich schon beim Installieren / Einrichten von ADS Probleme, da ich nicht weiß, was ich wie einbinden muss.
Das ist der Punkt, an dem ich um Hilfe bitte.
Außerdem wäre es interessant zu wissen, ob es tatsächlich der ADS von SAP ist, den ich installieren muss.

LG, unicorn

unicorn hat geschrieben: ↑Mi, 22. Nov 2017 12:15Außerdem wäre es interessant zu wissen, ob es tatsächlich der ADS von SAP ist, den ich installieren muss.

Den ADS gibt es ja nur von SAP. Woher sollte man den also sonst nehmen?

Zur Installation: Ich habe sehr gute Erfahrungen damit gemacht, da Joachim mit ins Boot zu holen. Der ist halt absoluter Spezialist dafür. Ist sehr zuvorkommend (gibt ja hier im Forum als nightcrawler auch ständig Support zum ADS), und wenn das dann real zum Tragen kommt nimmt er nicht viel Geld. Auch, da die gesamte Installation innerhalb 1/2 Stunde durch ist mit Allem, was so dazu gehört.

Jan

Der Unterschied zwischen dem direkten Zugriff (per DBFNTX-DBE) und demjenigen z.B. per ADS (ADSDBE) besteht darin, dass beim direkten Zugriff die Dateien einzeln und mehrfach (je Arbeitsplatz) auf dem Server geöffnet werden. Für Suchoperationen und ähnliches wird auf dem Serverlaufwerk gelesen und die zu überprüfenden Datenmengen werden Stück für Stück zum Arbeitsplatz übertragen (dort ist die Logik) und dort analysiert. Es wird zwar keine lokale Kopie einer DBF angelegt - das wäre sehr, sehr langsam -, aber wenn man zum Beispiel eine komplette Tabelle filtert, muss sich die Workstation Stück für Stück den Inhalt der Datei tatsächlich holen und prüfen. Läuft ein Datenbankserver, so öffnet dieser erstens jede Tabelle nur ein einziges Mal, ganz unabhängig davon, wie viele Arbeitsplätze über ihn auf diese Tabelle gleichzeitig zugreifen. Er liest die Tabelle natürlich auch Stück für Stück (im Zweifelsfall komplett), wenn darin aufwendig gesucht wird, aber er übermittelt an die Arbeitsplätze nur das Ergebnis der Suche, also die zutreffenden Datensätze/Felder. Außerdem sorgt er für Integrität. Er ist viel stabiler. Allerdings ist die ADSDBE von Alaska nicht gerade optimiert. Im Normalbetrieb wird der Geschwindigkeitsgewinn gering sein, möglicherweise wird die Anwendung sogar langsamer, zumindest im Vergleich zum lokalen Direktzugriff. Aber meistens lohnt sich der Einsatz.

Beim Installation des ADS ist eigentlich nicht viel zu beachten, das ist sehr unkompliziert. Wichtig ist nur, dass der Zeichensatz stimmt, vor allem, wenn man noch mit OEM (DOS-Zeichensatz) arbeitet. Das muss dann (2x!) so gesetzt sein.

Die Einbindung ist vergleichsweise unkompliziert. Man muss in der Anwendung die Verbindung zum Server aufbauen und prüfen, wodurch ein Session-Objekt entsteht. Dann muss man ein paar Parameter setzen, aber nicht viele. Mehr Code muss eigentlich nicht verändert/hinzugefügt werden.

Hallo Tom,

zur Geschwindigkeit: Nach der Einführung des ADS mit proprietärem Zugriff bei meinem Kunden dauert das Öffnen der dbf sehr lange, gerade bei sehr umfangreichen dbf (bis zu 4 GB groß). Die Zeit dafür hat sich ca. verdreifacht. Aber der Betrieb danach ist hier wesentlich beschleunigt worden.

Allgemein:

Wichtig finde ich noch zu sagen, das es sehr sinnvoll ist, wenn das nicht ohnehin schon passiert ist, die dbf auf FOXCDX zu konvertieren. Das hat einige Vorteile. Bei meinem Kunden insbesondere, das unter dem ADS die Anzahl der Indizee je dbf beim DBFNTX begrenzt ist (waren das 20?). Mein Kunde hat aber teilweise noch viel mehr. Und die Begrenzung gilt nicht für FOXCDX.

Wichtig ist auch, das die dbf keinen Alias länger als 10 Zeichen haben dürfen, ebenso die Indexnamen. Das mag der ADS gar nicht, das gibt Laufzeitfehler wegen unbekannter Dateinamen. Man muß die entsprechend kürzen (was bei Alias ja nicht wirklich ein Problem ist, man muß nur dran denken)

Jan

Jan hat geschrieben: ↑Mi, 22. Nov 2017 13:45...
zur Geschwindigkeit: Nach der Einführung des ADS mit proprietärem Zugriff bei meinem Kunden dauert das Öffnen der dbf sehr lange, gerade bei sehr umfangreichen dbf (bis zu 4 GB groß). Die Zeit dafür hat sich ca. verdreifacht.
...

Ob das Öffnen nun 0,0001 Sekunden oder 0,0003 Sekunden dauert spielt doch keine Rolle, oder?

Uli

Uli,

richtig. Aber ob das Öffnen von 58 dbf 8 oder 25 Sekunden dauert, dann doch schon. Klar, das ist bei dem Kunden nur einmalig beim Programmstart. Aber stört dann doch schon ein wenig.

Jan

Jan hat geschrieben: ↑Fr, 24. Nov 2017 8:05 Uli,
richtig. Aber ob das Öffnen von 58 dbf 8 oder 25 Sekunden dauert, dann doch schon. Klar, das ist bei dem Kunden nur einmalig beim Programmstart. Aber stört dann doch schon ein wenig.
Jan

Das ist in jedem Fall viel zu langsam um nicht zu sagen unbrauchbar...

Jetzt aber...
wie kommt Ihr auf solche Zeiten?

Habe gerade mal nachgeschaut:
Total User: 50
Connections: 45
Work Areas: 1562
Tables: 143
Index Files: 412

In Sekundenschnelle wird die Haupt-App geöffnet. Meine Kunden würden sich da stündlich beschweren!

Das hört sich schwehr nach zu schwachem Server an.

Das ist aber was für Mr. Dirr, der weiß da bestimmt mehr über den Durchsatz.

Ich vermute, dass im Hintergrund das Öffnen der Tabelle zunächst scheitert (mit Time Out). Anschließend wird die Tabelle anders erfolgreich geöffnet. So etwas ähnliches hatte ich zu Beginn meiner ADS-Zeit mal gehabt und kann ich teilweise heute noch beim ARC (=Data Architect) beim erstmaligen Öffnen einer Tabelle nachvollziehen.