Erfahrungen mit SQL-Servern

alles was zunächst nicht kategorisierbar ist

Moderator: Moderatoren

hschmidt
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 164
Registriert: Mo, 09. Jan 2006 17:06
Wohnort: Paderborn
Hat sich bedankt: 2 Mal
Kontaktdaten:

Erfahrungen mit SQL-Servern

Beitrag von hschmidt »

Hallo,

hat jemand hier im Forum Erfahrung mit der Anschaltung von SQL-Datenbankservern (z.B. MS SQL-Server oder MySQL)?
Dabei interessiert mich insbesondere, ob es möglich ist, eine entsprechende Datenbank ohne große Codeänderungen einzubinden.

Hintergrund: wir arbeiten schon jahrelang mit ADS und koppeln unser Programm über die ADSDBE an den ADS-Server. Dabei kann ja die aus den DBF-Datenbanktreibern bekannte Syntax (DBSeek, DBSkip, DBGoto etc....) nahtlos weiterverwendet werden. Bisher waren wir mit dem ADS auch sehr zufrieden, es zeigt sich jetzt allerdings, das die Datenbank bei deutlich über 100 konkurrierenden Usern an ihre Grenzen stößt.

Meines Wissens nach ginge die Anbindung über den ODBC-Datenbanktreiber von ALASKA oder über Drittprodukte (SQL-Express?).
Gibt es weitere Möglichkeiten? Wie umfangreich muß der Code geändert werden? Wie ist die Stabilität und Performance auch bei großen Datenbeständen mit sehr vielen Anwendern?

Vielen Dank im voraus!

Hans
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Beitrag von Jan »

Hallo Hans,

nach dem, was auf der Alaska-Homepage vorstellt wurde (Hot News vom 20.9.2007), und was wir in Berlin gehört haben, reicht mit einem der kommenden Releases eine einzige Codezeile aus, um auf SQL umzustellen.

Im Moment ist das wesentlich aufwändiger, wobei ich selber das noch nie gemacht habe, da also auch nicht viel zu sagen kann. Sehr beliebt ist dazu aber in jedem Fall das Tool von Boris Borzic, SQLExpress.

Jan
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

SQL - ist eine schöne Sache!
Die Umstellung ist aber aus meiner Erfahrung nicht so einfach, wenn mit ODBCDBE gearbeitet wird!
Vor Jahren, wo wir unser Programm auf SQL umgestellt hatten, hatten wir viele Probleme. Mittlerweile haben wir eine eigene Klasse, die alles abwickelt und direkt mit den SQL-Befehlen arbeitet.

Ich würde aber vielleicht wirklich auf die neue XBase++-Version warten, wie Jan es schon gesagt hat.
Zumindest warte ich ungeduldig darauf!
Gruß,

Andreas
VIP der XUG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hi,

das was in Berlin vorgestellt wurde hörte sich sehr gut an (nahtlose Integration von SQL speziell PostGreSQL-SERVER in Xbase++), aber darauf warten würde ich nicht !

Die ODBCDBE ist nach meiner Erfahrung ganz nett, wenn man z.B. aus Excel oder Access Daten holt. Sicherlich kann man diese auch für große Datenbestände nutzen, aber die Aussage 'kaum Codeänderungen und es läuft' kann nicht stimmen. Ein SQL Server ist nun mal etwas anderes als eine DBF (der Server muss die Daten filtern, wird hier unsauber alles angefordert und dann auf dem Client gefiltert, ist die Performance schnell im Keller und das für alle Anwender). Wenn Ihr bisher mit ADS gearbeitet habt, kann es natürlich sein, dass ihr das alles schon eingebaut habt. Wenn man viele Anwender hat, muss man sich natürlich auch mit der Serverseite beschäftigen und sich dort auskennen.

Ich selbst habe in der Version 1.80 oder 1.82 mit der ODBCDBE experimentiert und mich dann zum Kauf von SQLExpress entschlossen. Dieses Produkt funktioniert - für meine Verhältnisse - einwandfrei und ich kam damit einfach besser zurecht. Das muss natürlich nicht für jeden stimmen ;-)

Phil hatte für den PostGreSQL Server noch eine DLL entwickelt, aber seine Seite ist nicht mehr aktiv :-(
Gruß
Hubert
Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Beitrag von Alfred »

Hallo Hans,

kenne ADS nicht. Ich versuche gerade eine Foxpro 2.6(dbf) nach Alaska und MySQL zu bringen. Aufgrund meiner bisherigen Erfahrungen kann ich folgendes sagen:

- Alaska ODBCDBE und eXpress++ wollen nicht so richtig miteinander.

- Alaska ODBCDBE und das ändern von Daten im Browser habe ich
noch nicht zustande gebracht

- deutsche Umlaute sind ein Problem das gemeistert sein will.
- Ein Lazarus-Programm hat mir gnadenlos UTF8 in eine
latin1-Datenbank geschrieben, obwohl dies MySQL eigentlich
per Definition verhindern sollte.

- Sortierung nach deutschen Umlauten muss in der Datenbank und
in der Tabelle hinterlegt sein

- Datumsformat in MySQL ist amerikanisch ablegt

- Konkurrierende Zugriffe sind in MySQL so geregelt, dass der zuerst
kommt, zuerst abgearbeitet wird . Alles andere muss man selbst
regeln. Fragt sich nur wie.

Ich würde dir empfehlen einen MySQL-Server(auf PC oder Server) für
Testzwecke einzurichten, da dies unter Windows sehr einfach zu er-
ledigen ist.

Die Testversion von SQLExpress(von Boris Borzic) ist ebenfalls zu empfehlen.

Problematisch sind jedoch die Administrationstools. Unter Windows kann
ich nur zu Heidi-SQL raten.

SQL-Express von MS hat laut einem Bekannten ebenfalls Probleme mit
den deutschen Umlauten beim sortieren.

Grundsätzlich solltes du die Lizenzfrage nicht aus den Augen verlieren.
Beide Produkte kosten richtig Geld, wenn sie beim Kunden eingesetzt
werden sollen.

Gruß
Alfred
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Beitrag von Jan »

Hubert hat geschrieben:aber die Aussage 'kaum Codeänderungen und es läuft' kann nicht stimmen. Ein SQL Server ist nun mal etwas anderes als eine DBF (der Server muss die Daten filtern, wird hier unsauber alles angefordert und dann auf dem Client gefiltert, ist die Performance schnell im Keller und das für alle Anwender).
Das war ja teilweise Thema des Vortrages von Boris. Und ich kann das auch teilweise nachvollziehen. Der Zugriff ist einfach komplett unterschiedlich, daher gibt es da auch entsprechende Umarbeitungszeit. Und SQL ist für alte Clipperianer wirklich eine neue Welt, das ist wie damals, als wir nach dem Wechsel zur Windowsprogrammierung mit Alaska OOP lernen mussten.

Ich bin mir einfach nicht sicher, ob Boris das gesagt hat, um sein Produkt zu retten, oder ob das wirklich so dramatisch ist. Ganz sicher wird es eine Einbuße bei dem System von Alaska geben. Aber wie dramatisch das ist, daß muß die Erfahrung zeigen, wenn das raus ist. Und danach vermutlich das 1. Hotfix darauf. Ich setze allerdings darauf, daß das von Anfang an sehr ausgereift sein wird. Denn inzwischen arbeiten die mindestens 14 Monate da dran.

Aber man muß auch das bedenken, worauf Steffen in Berlin ganz zu recht hingewiesen hat. SQL ist nicht die alles rettende Geschichte. Sehr oft geht es auch ohne, und sehr oft geht es ohne auch einfacher und schneller. Aber ebenfalls sehr oft ist SQL für uns Entwickler schlicht ein Muß, weil der Kunde das fordert, ob nun zu Recht oder nicht.

Jan
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hi,

@Alfred,

in mehreren Threads in den Alaska Newsgroups wurde über SQL Server diskutiert. MySQL hat danach erhebliche Probleme wenn es in den konkurierenden Schreibzugriff geht. Für meine privaten Spielereien geht es ganz gut, aber PHIL hat damals PostGreSQL über den Klee gelobt. Ähnliches hat ja auch Stefen in Berlin gesagt UND er ist immer frei auch beim Endkunden wenn du ihn mitlieferst !

Aus diesen Gründen würde ich heute nur noch mit PostGreSQL beginnen.

Der kleine Microsoftserver (SQL Express) ist - soweit ich weiß - heute komplett frei und kostenlos, aber für das Massengeschäft nicht zu gebrauchen (dafür gibt es ja den großen ;-) )

@JAN,

ich bezog meine Aussage auf die aktuelle ODBCDBE. Was die zukünftige Version von 'Arktika' bringt, weiß kein Mensch. Warten würde ich darauf aber nicht. SQLExpress kostet nicht die Welt und ist ausgereift.

Was ich hauptsächlich mit der Programmierung meinte ist, dass es eben nicht reicht mal kurz den ODBCDBE SQL Connectstring vor USE zu setzen und den Rest einfach zu belassen, es geht zwar schon - meist irgendwie - aber schnell wird das nicht.

Was das brauchen angeht, so habe ich selbst noch keine Notwendigkeit bei mir erkannt, aber ich habe auch keine 50 Mann die im Netzwerk konkurierend Schreiben in meinen DBFs, sondern pro Anwendung maximal 20 oder mach es anders. Irgendwann über diesen Zahlen steigen die Probleme - wie man überall liest - wohl dramatisch an, sonst würde ja niemand die ADS kaufen ;-)

Gerade bei größeren Firmenkunden sind aber Anwendungen mit DBF Dateien - obwohl wirklich super - einfach schwer an den Mann zu bekommen. DBF - dBase = alte Technik ist leider ein Vorurteil das kaum zu bekämpfen ist.
Gruß
Hubert
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Beitrag von Jan »

Hubert,

auch ich habe keine Ahnung, was Arctika bringen wird. Aber das, was Steffen angekündigt hat, ist eben sehr vielversprechend. Und so wie er das erklärt hat, kann ich mein Use und DbSkip() etc. behalten, es muß einfahc nur irgendwo eine Zeile eingefügt werden. Die dann dem System sagt, daß jetzt SQL gesprochen wird. Ob die dann im Präprozessor alle satzorientierten Befehle auf mengenorientiert umbauen, weiß ich nicht. Aber ich könnte mir vorstellen, daß die Performance leiden wird. Und das war das, was ich meinte. Und was Boris und Steffen in Berlin versucht haben zu erklären: Einfach nur irgendwelche SQL-Syntax einzubauen bringt erstmal noch überhaupt garnichts.

Und Dein letzter Absatz beschreibt ja genau das Problem, das wir haben: Kunden, die Ahnung haben (oder meinen, sie zu haben) verstehen unter "Professioneller Software" grundsätzlich SQL. Ob das nun im Detail sinnvoll ist oder nicht.

Aber dennoch muß man natürlich sagen, daß SQL zumindest in einem Punkt einen Vorteil für uns Entwickler hat: Die Datenkonsistenz bei einem Absturz des Servers oder Clients. Da das bei SQL intern geregelt wird, ist das immer sicherer als alles, was ich bei dbf manuell schreiben könnte.

Ich werde in jedem Fall auf Arctika warten. Ich brauch das nicht unbedingt. Aber ich möchte meinen Kunden, die partout SQL fordern, das dann alternativ anbieten. Wenn das performancemäßig keine Negativwerbung wäre. Das gilt allerdings speziell für mich, der ich bislang ohne jede 3rd-Party-Produkte arbeitet und auskommt. Und der ich meine bestehenden Projekte dann nicht gnadenlos überarbeiten müsste. Denn DAS ist in der Tat ein unglaublicher Aufwand. Und damit auch Fehleranfällig.

Jan
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21165
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 206 Mal
Danksagung erhalten: 67 Mal

Beitrag von Manfred »

Hi,

ich meine mich erinnern zu können, das von Ende 2008 die Rede war. War das jetzt VX 2.0 oder auch Arktika? Ich weiß es nicht. Aber denkt bitte daran, wie die Vergangenheit war. Es wird sicherlich eher Mitte 2009 werden, als Ende 2008. 1,5 Jahre noch. Das ist eine Menge Holz zum warten.

Warten wir aber mal ab, ob in den nächsten Tagen ein Release für 1.9 kommt.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Beitrag von Tom »

@Jan: So isses. SQL-Server und dateibasierte Datenbanksysteme, die satzorientiert arbeiten, wenden völlig unterschiedliche Paradigmen an. Man kann eine SQL-Datenbank dazu kriegen, satzorientiert zu arbeiten, aber genaugenommen mißbraucht man das System - und man verzichtet auf das, was eigentlich ein Vorteil wäre. Ich bin sicher, daß die Performance bei nativem SQL-Zugriff (z.B. mit SQLexpress) deutlich höher liegen dürfte, als bei einer DBE, die alle Datenbankzugriffe kapselt und auf irgendeine Art ein DbGoto() generiert, das es eigentlich nicht gibt. SQL liefert Cursor (Current Record Sets) zurück, wenn man Daten abfragt, was dem Standardverhalten unserer DBEs (FOX/DBF) völlig widerspricht, da wir immer auf der Datenschicht direkt arbeiten. Es ist also anzunehmen, daß jede Menge Code dafür sorgen wird, daß sich die SQLDBE so verhält, als wäre es eine DBFDBE, und das zu Lasten der Performance. Andererseits fragt sich, ob in Zeiten von Terrabyte-Platten, Gigabit-Netzen und Gigahertz-Workstations derlei noch tatsächlich eine spürbare Rolle spielt.
Herzlich,
Tom
Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Beitrag von Alfred »

Der zusätzliche Programmieraufwand den Tom beschrieben hat, führt zu folgenden Problemen:

Bei Omnis Studio 4.2 kann man im Dataset standardmäßig nur vorwärts blättern.

Bei Lazarus mit SQLdb stehen bei einem Update mit mehr als 9 Feldern
ab dem 10. Feld unsinnige Werte in der Datenbank.

Bei Alaska(ODBCDBE) und eXpress++ werden beim editieren im DCBROWSE
die Daten richtig in die Datenbank geschrieben, aber im DCBROWSE beim
verlassen des Feldes die alten Werte angezeigt.

Gruß
Alfred
Benutzeravatar
andreas
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 1902
Registriert: Mi, 28. Sep 2005 10:53
Wohnort: Osnabrück
Hat sich bedankt: 4 Mal
Kontaktdaten:

Beitrag von andreas »

Satz orientiert mit SQL über ODBCDBE zu arbeiten hat bei mir garnicht funktioniert oder ich habe was falsch gemacht. :?
Deswegen habe ich das ganze Programm auf SQL-Befehle umgestellt bzw. ich erzeuge Arrays mit den zu speichernden Daten und übergebe diese an meine Klasse, die dann SQL-Befhel daraus baut und diesen ausführt.

Im Zusammenhang mit MS SQL Server und ODBCDBE gibt es aber auch Probleme mit Text-Feldern (Memo), wo die bei bestimmten Bedingungen im Programm nicht angesprochen werden können, was aber bei einzelnen Sätzen umgegangen werden kann.

Es gibt dann im gleichen Zusammenhang auch andere Kleinigkeiten, wie z.B. dass die Abgerufenen Daten kein EOF() liefern und was bei den Schleifen extra überprüft werden muss, da man sonst hängende Programme hat.
Gruß,

Andreas
VIP der XUG Osnabrück
Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Beitrag von Alfred »

Was man bei diesen SQL-Servern auch nicht vergessen darf, wer installiert
denn den Server. Wer aministriert ihn. Was ist, wenn schon ein MySQL-Server
vorhanden ist? MySQL und Firebird wollen zudem auf jedem Rechner einen Client.

Für meinen persönlichen Bedarf mag dass ja noch angehen. Bei einem
Kunden mit vielen Rechner und unterschiedlichen Betriebssystemen wird
das mit Sicherheit aufwendig und der EDV-Leiter wird darüber sicher nicht
erfreut sein.

Gruß
Alfred
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Hi,

was für einen Client braucht denn MySQL ?

ich habe nur die ODBC Verbindung auf den Server eingerichtet und nutze nun diese. Das soll auch per Programm gehen, habe ich aber nicht probiert. Den Adminclient habe ich nur auf einem PC. Oder meinst du den ODBC Treiber ... ist schon eine Weile her und mit PostgreSQL habe ich noch nicht angefangen.
Gruß
Hubert
Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Beitrag von Alfred »

Hallo Hubert,

vielen Dank für deinen Hinweis.

Da war ich voll im Wald gestanden. Meine mit Lazarus produzierte *.exe will auf einem anderen Rechner noch eine libmysql.dll im Programmverzeichnis haben.

Gruß
Alfred
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Beitrag von brandelh »

Alfred hat geschrieben:Meine mit Lazarus produzierte *.exe will auf einem anderen Rechner noch eine libmysql.dll im Programmverzeichnis haben.
Was ist Lazarus ?
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Beitrag von Tom »

Herzlich,
Tom
hschmidt
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 164
Registriert: Mo, 09. Jan 2006 17:06
Wohnort: Paderborn
Hat sich bedankt: 2 Mal
Kontaktdaten:

Beitrag von hschmidt »

Hallo,

vielen Dank für die Antworten und die lebhafte Diskussion.
Es war mir eigentlich schon vorher klar, das es keinen wirklich einfachen Weg für die Migration von ADS zu einem 'echtem' SQL-Datenbankserver gibt.
Unser Problem ist bei Sybase durchaus bekannt und hängt damit zusammen, dass mit der 32 bit-Version nur 4 GB Haupspeicher adressiert werden können, was eben bei der besagten Anzahl von Usern eng werden kann. Eine Lösung dieses Problems durch ADS wird es mit der 64 bit-Version geben, von der aber niemand genau weiß, wann sie kommt.

Na ja, ich denke, ich sehe mir die Demo von SQL-Express an, wenn ich Euch richtig verstanden habe ist die ODBCDBE nicht das richtige Werkzeug.

Hans
Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Beitrag von Alfred »

Hallo Hans,

ich musste wegen Umstellung meines Samba-Servers von FC6 nach FC8
auf PostgreSQL 8.2.6 umsteigen. Mit PgAdmin III 1.8.2. kann man damit
gut arbeiten.

Das Tool Navicat 8 for PostgreSQL(30 Tage Trial) ist sehr zu empfehlen.
Ein Highlight sind die Exportfunktionen mit integierter Zeichensatzauswahl
zu Excel und Access.

Bitte beachte, dass beim Anlegen im initdb Befehl die Locale richtig
gesetzt werden muss, da sie später zum Sortieren gebraucht wird
und es derzeit kein Tool gibt dies nachträglich zu ändern.

Für die richtige Sortierung des großen Ä muss man in die Trickkiste
greifen, aber das ist keine großer Aufwand.

Gruß
Alfred
hschmidt
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 164
Registriert: Mo, 09. Jan 2006 17:06
Wohnort: Paderborn
Hat sich bedankt: 2 Mal
Kontaktdaten:

Beitrag von hschmidt »

Hallo Alfred,

und benutzt Du ein Alaska-Xbase-Programm als Frontend für die PostgreSQL-Datenbank?
Wenn ja, mit welcher Technik greifst Du auf die Daten zu?

Hans
Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Beitrag von Alfred »

Hallo Hans,

meine Grundsatztest mit SQL-Datenbanken mache ich mit Lazarus und die
waren mit der neuen Version positiv. Da ich derzeit beruflich viel zu tun
habe, konnte ich weitere Test noch nicht durchführen.

Ich habe aber mein SQL-Express-Beispiel für PostgreSQL abgeändert und
es funktionierte sofort.

Code: Alles auswählen

#define __CONNECT_STRING    'DSN=PostgreSQL30;UID=meine;pwd=mypwd'
#define __TABLE         'public.Personal'
#define __STATEMENT 'SELECT * FROM '+'"public"."Personal" order 
by "public"."Personal"."Name"'
Beachte bitte die Hochkommas und das "public" vor dem Feldnamen. Scheint eine Eigenart von PostgreSQL zu sein. Habe ich so von Navicat 8 abgeschaut.

Außerdem muss man bei Linux-Servern die Groß- und Kleinschreibung
bei den Dateinamen beachten und die Zugriffsberechtigungen sauber verwalten.

Gruß
Alfred
Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Beitrag von Alfred »

Hallo Hans,

hier noch der Trick mit dem Ä.

Code: Alles auswählen

#define __STATEMENT 'SELECT * FROM '+'"public"."Personal" ORDER BY Regexp_replace("public"."Personal"."Name",'+chr(39)+'Ä'+chr(39)+','+chr(39)+'Ae'+chr(39)+')'
Gruß
Alfred
Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Beitrag von Alfred »

Hallo Hans,

hier noch ein Tipp zum Testen:

Navicat 8 for PostgreSQL hat einen sehr guten Import-Wizzard für dbf(auch
FoxPro).

Gruß
Alfred
Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Beitrag von Alfred »

Hallo Hans,

zu deinen Überlegungen folgende Information:

Jede 8.X Version bedeutet ein Upgrade. Dies hat zur Folge, dass von der
Datenbank ein Dump erstellt und dann in die neue Version eingelesen
werden muss. Der Haken ist nun, dass für diese Aktion die alte und die
neue Version parallel auf dem Server laufen müssen und der Dump von
der neuen Version ausgeführt werden muss.

In meinem Fall lässt Fedora 8 jedoch standardmäßig keine parallele
Installation von 2 Programmversionen zu. Mit Debian geht das angeblich.
Der Versuch an der Standardversion vorbei die neue Version zu
installieren ist mir nur mit erheblichen Aufwand gelungen. Der Auf-
ruf der initdb(8.3) erzeugte erst nach dem Löschen aller 8.2 Program-
me die richtige Datenbank. Die manuelle Installation des erforderlichen
pgadmin(für 8.3) unter Fedora ist mir auch noch nicht gelungen. Ich
habe erstmal das Umsetzen der Daten eingestellt und mit Navicat die
Daten in die neue Version überführt.

Das ein Produktivsystem ein Upgrade der Daten nicht automatisch vor
nimmt ist mir absolut unverständlich.

Im Internet habe ich auch noch gelesen, dass ein Dump mit mehr
als 4GB Probleme bereitet.

Gruß
Alfred
Alfred
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 476
Registriert: Do, 03. Mai 2007 12:37
Wohnort: München

Beitrag von Alfred »

Hallo Hans,

zum Thema MS-SQL Server kann ich noch folgendes beitragen.

Meine EDV-Genossenschaft setzt für die Mandatenversion ihres Buch-
haltungsprogrammes seit der Version 19.0 auf SQL-Express von MS.
Bei der Installation des Servers wird auf die Installationsroutinen von
MS zugegriffen, die völlig unsinnige Fehlermeldungen ausgeben, mit
denen sogar ich nichts anfangen konnte. Man stellte mir dann 10 Seiten
zur Problemlösung zur Verfüung. Die ganze Aktion hat mich für einen
Kunden 2 Arbeitstage gekostet. Auf dem Rechner des Mandaten war im
übrigen nur die funktionsfähige Vorgängerversion des Buchhaltungspro-
grammes installiert.

Gruß
Alfred
Antworten