Inoffizielles deutsches Xbase-Forum

irgendwie komme ich nicht weiter, ich meine mich erinnern zu können irgendwo eine Checkbox anzuklicken um den local Server zu installieren. Wie bekomme ich den auf den PC? War das im Architekten? ich finde nichts dazu. Also, wie installiert man den local Server?

War das nicht nur ein Eintrag in der ini-Datei (oder condig)?

Viele Grüße,
Martin

ich bin der Meinung, das der local Server kostenlos ist (ist ja abgespeckt und für Testzwecke sicherlich gedacht). Wenn man aber den ADS installieren will um dann die COnfig zu ändern, dann geht das nicht ohne Seriennummer usw. Aber die hätte man ja nicht, weil man ja keinen vollwertigen ADS Server hat, bzw. installiern will. Oder hat SAP das auch geändert?

Der Local Server sind nur ein paar Dateien (adsloc32.dll und adslocal.cfg), die benötigt werden. Da muss nichts installiert werden. Der ist nicht nur für Testzwecke sondern auch für den lokalen Einsatz gedacht.
Für Testzwecke gibt es eine 2-User-Entwicklerversion.

und wie wird der dann gestartet?

Gar nicht. Das ist ja kein selbständiges Programm. Ich meine die DLL wird direkt von der ACE32.dll aufgerufen.
Ich bin da nicht mehr so drin, dass ich das mal eben runterschreiben kann. Eventuell war es so, dass man im Data Dictionary angeben muß, dass der Zugriff als "Local Server" erfolgt" (Server Type Local).

Manfred,

was willst Du damit machen? Ich kann Dir davon nur abraten, ist sehr langsam und stark eingeschränkt.

Warum gehst Du nicht endlich auf PostgreSQL? Auch für Deine Bilder-Anforderung? ADS ist letztes Jahrtausend und (bald) tot!

ADS local ist in allen Zugriffsvarianten deutlich weniger performant als direktes DBFCDX oder eine andere dateibasierte DBE. Das ist bestenfalls als "fall back" oder für Test-/Entwicklungszwecke sinnvoll. Ansonsten kann ich mich Werner nur anschließen. Jede Investition in irgendwas, das mit dem ADS zu tun hat, ist spätestens mittelfristig verschenkt. Und, unter uns: Mit der ADSDBE sind die Vorteile des ADS auch nur spürbar, wenn man sehr genau hinfühlt oder extrem stark belastete Netze hat. Das ist mit der PGDBE völlig anders.

Danke für eure Anteilnahme, aber das Problem ist gar nicht so trivial.
Wenn ich den ADS in der von mir betrachteten Umgebeung nehme, dann stülpe ich den drüber und gut ist (zumindest grob gesehen). Das kann man unter den Umständen mit dem Postgres nicht so machen.
Weiterhin muß die Möglichkeit bestehen on the fly ein lokales System zu erzeugen (für ein Notebook zum Mitnehmen) und dafür sollte dann der local ADS herhalten. Ob das mal eben so mit dem Postgres geht? Ich habe keine Ahnung. Mir gefällt das auch nicht alles so, wie es läuft....

Es sind 5 Dateien, welche direkt von der APP über ACE32.DLL geladen werden uns somit im gleichen Verzeichnis wie die ACE32.DLL liegen müssen
- adsloc32.dll
- adslocal.cfg => hier - ansi.chr
- extend.chr
- axcws32.dll // die wird ohnehin immer benötigt.

In der Connection musst du den Local Server als SERVER_TYPE= 1 übergeben, oder eine ADS.INI ins gleiche Verzeichnis stellen: 1 = Local Engine
2 = Remote
1+2 = beides, wenn kein Remote gefunden, dann local
Die Dateien sin im ARC Verzeichnis zu finden.
Ansonsten gelten die Kommentare von Werner und Tom

@Tom,

Mit der ADSDBE sind die Vorteile des ADS auch nur spürbar, wenn man sehr genau hinfühlt oder extrem stark belastete Netze hat.

Ich finde schon, dass im Netzwerk der Zugriff (teilweise) schneller ist und die Index-Korruption nahezu nicht mehr stattfindet.
Aber bezüglich PGDBE warten wir ja noch auf einen Vortrag / Online Meeting / Workshop bezüglich der notwendigen Änderungen im Code von Dir

Hallo, Wolfgang.

Ich finde schon, dass im Netzwerk der Zugriff (teilweise) schneller ist und die Index-Korruption nahezu nicht mehr stattfindet.

Im (vor allem stärker) konkurrierenden Zugriff gibt es irgendwann Performancevorteile, ja - vorher allerdings kaum. Und das mit der Korruption stimmt natürlich.

Aber bezüglich PGDBE warten wir ja noch auf einen Vortrag / Online Meeting / Workshop bezüglich der notwendigen Änderungen im Code von Dir

Klar. Ihr macht das alle nicht, weil Ihr auf einen Vortrag von mir wartet, sicher. Ich mache meine strategischen Pläne ganz ähnlich.

Servus Wolfgang,

Du hast funktionierende Beispiele in der Alaska-Hilfe und in meinem Vortrag aus Münster. Viele PDRs seit damals sind erledigt, einige neue sind dazugekommen. Umstellung auf ISAM-SQL ist relativ einfach, ähnlich wie ADS.

Einschränkungen nach wie vor:

• Bei größeren Datenmengen (> 100.000 Datensätze) extrem langsam und teilweise Abstürze (z. B. Browse)

• Code muss immer noch überarbeitet werden, z. B. wenn beim Editieren ein Indexfeld geändert wird - siehe mein Vortrag

• Mischen von Pass-Through mit ISAM-SQL kann sehr problematisch werden (z. B. delete, update von Feldern, die einen Index haben etc.)

Ich hab vor 1 Jahr für einen Kunden unsere Waren-Wirtschaft umstellen müssen, weil seine Artikel-DBF > 2 GB wurde (1.2 Mio DS aktuell). Dachte, ich mach das mal schnell an einem Tag... Trotz meiner langjähriger Erfahrung mit PostgreSQL - ausschließlich Pass-Through - ist das bis heute noch nicht komplett umgestellt, war sehr aufwändig aus o. g. Gründen. Ein DbPack() z. B. dauert auf einem lokalen (!) PG 14 > 14 Stunden! Ist also nicht praxistauglich.

Du kannst das doch einfach mit einem #IFDEF PGSQL im Code testen. Vorher einfach ein upsize (auch Beispiel Alaska-Hilfe und mein Vortrag) und fertig. Wennst die o. g. Punkte nicht hast, ist die Umstellung so einfach, wie sie in der Hilfe von Alaska steht. Einfach die Punkte beachten (z. b. file() - Abfragen).

Ansonsten weg von ADS und DBF und hin zu PG! Macht mittels Pass-Through einfach nur Spaß, ist sauschnell (sogar bei einer VPN-Verbindung, oder wenn der PG z. B. nur auf einem NAS läuft), der Code wird viel schlanker und besser wartbar! Und man hat soviele neue Möglichkeiten und kommt damit endlich mal Richtung Stand der Technik!!! Stichpunkte Verschlüsselung, Datensicherheit, Zugriffsschutz, DSGVO-Umsetzung viel einfacher, Stabilität etc.

Werner_Bayern hat geschrieben: ↑Mo, 13. Feb 2023 1:39 ADS ist letztes Jahrtausend und (bald) tot!

lt https://de.wikipedia.org/wiki/PostgreSQL ist PostgreSQL am 8. Juli 1996 erschienen, also auch letztes Jahrtausend;) Ansonsten hast Du natürlich recht. ADS ist tot.

Ansonsten hast Du natürlich recht. ADS ist tot.

und ich habe mich schon gewundert, warum das hier so komisch riecht.

Manfred hat geschrieben: ↑Mo, 13. Feb 2023 15:55

Ansonsten hast Du natürlich recht. ADS ist tot.

und ich habe mich schon gewundert, warum das hier so komisch riecht.

Ich wollte tatsächlich schon oben schreiben, es riecht nach Verwesung! Witzig!

Nachtrag, weil ich aufgrund meines Beitrags von heute aktuell nochmal der ISAM-SQL-Unterstützung auf den Zahn fühle - Alaska hat da ja in den letzten ca. 20 Updates enorm viel gemacht: Es gibt auch tolle neue Fehlermeldungen wie

Betriebssystem : Windows 11 2009 Build 22621
Runtime : Xbase++ (R) Version 2.00.1689
------------------------------------------------------------------------------------------
oError:args :
-> VALTYPE: C VALUE: gruppe.ntx
oError:canDefault : N
oError:canRetry : J
oError:canSubstitute: N
oError:cargo : NIL
oError:description : Fixkeys rebuild failed.
oError:filename :
oError:genCode : 8999
oError:operation : OrdListAdd
oError:osCode : 0
oError:severity : 2
oError:subCode : -168546110
oError:subSystem : BASE
oError:thread : 1
oError:tries : 1
default DBE : PGDBE

Werner, passiert das nur beim Local Server Zugriff?

Edit: hat also gemäß Tom nix hier im Faden zu suchen .

Das ist eine PGDBE-Meldung, Uli. Nix mit ADS.