Hi Delphianer,

wir entwickeln und vertreiben ein Software mit einer DB in ACCESS. Bisher bieten wir nur eine Single-Client Version an. Um ein UPSize auf eine Client-Server-DB zu erhalten, probieren wir derzeit MS-SQLServer aus (und da speziel den UPSize-Assistenten). Wie das ganze technisch abläuft, kriegen wir sicher bald raus.

Was mich interriessiert ist:

1. Wer hat das ganze prozedere mit dem Upsizen schon hinter sich und kann mir seine Erfahrungen mit MS-SQL-Server mitteilen.
   
2. Welche Probleme sind zu erwarten, wenn das ganze mal beim Kunden läuft.

Was soll ich sagen ? ... ALLES !!!!

Du weisst ja, wenn etwas erstmal beim Kunden ist, dann funzt gar nichts mehr. Aber für mich klingt das gerade so, als ob die größte umstellung dabei erstmal die ist, von einer single-user auf eine multi-user Anwendung zu wechseln. Und dabei kann ich dir nur raten, nochmal darüber nachzudenken, ob alle Datenbanktransactionen im Programm so programmiert sind, das mehrere Leute gleichzeitig auf einem Datensatz schreiben können und jeweils merken wenn etwas nicht commited werden kann. Denn das größte ärgerniss ist, ,wenn man erst 2 Tage später merkt, dass die Daten nicht übernommen worden sind.

Ein weiteres problem, was wir bei Kunden hatten, war das die Kosten für den Kunden bei dem Programm extrem gestiegen sind. (Durch MS-SQL-License). Wir sind dann deswegen auf Firebird (Opensource Interbase Datenbank) umgestiegen.

jeap,
gaaanz einfach. Man nehme Microsoft Office Enterprice (Professional glaub ich auch), da gibts die MSDE gratis dazu. Man installiere diejenige welche und ändere unbedingt die sa-accounts. Infos darüber bei MS.
Dann Access starten, upsize Assi aufrufen und ihm den Servernamen, kennwort und so'n kram geben und auf ok hauen.
zu 99.999% kriegt Access das alles rüber, ausnahmen sind hierbei access-typische Syntax bei procedures.

Aber wie mein Vorreder schon sagt, vorsicht ist zu geniesen, wenn das DB-Layout und die Anwendung nicht für Multiuser ausgerichtet ist. Also z.b. niemals mit ado-tables arbeiten, ist tierisch langsam. Besser Querries, adocommand oder alternative. BDE vergessen.

grez
msch

Danke Beni,

das mit den Server-Lizenzen ist derzeit auch mein größtes Problem. Wir verkaufen unsere Software für 1700?. Wenn wir in eine Multi-User-Version die Kosten für die Server-Lizenz berücksichtigen wird das ganz schön teuer.

@MSCH,

so einfach gings bei uns nicht. Die Daten sind zwar recht bald portiert aber der SQL-Dialekt bei ACCESS Jet und SQL-OLE-DB ist halt doch etwas anders.

Manfred

MKehrer hat folgendes geschrieben:

@MSCH, so einfach gings bei uns nicht. Die Daten sind zwar recht bald portiert aber der SQL-Dialekt bei ACCESS Jet und SQL-OLE-DB ist halt doch etwas anders.

Tja, imho ist aber access und MS-SQL zu 99 % kompatible. Zumindest was standard-SQL ist. Dat musste dann leider umschreibeln.

Was die Kosten betrifft, ist es usus, die Software von der eigentlichen DB zu trennen und ggf. dem Kunden die Wahl geben.
grez
msch

Wow. Fin dich gut, aber die SQL-Dialekte sind zurzeit wieder so verschieden, dass ich nicht weiss wie ich da ein Progg schreiben soll, welches auf MS-SQL und IB läuft. Es sind ja schlieslich alle Uppercases, Casts, etc. unterschiedlich. Abgesehen davon, das natürlich die Datentypen sich auch unterscheiden vom Namen her.

Und da ich sehr viel SQL direkt in Delphi progge wird das bei mir auf jeden Fall unmöglich. Aber ich lass mich gerne eines besseren belehren. Es kann natürlich auch sein, dass mein Programmierstiel schlecht ist.

Also ich würde gerne wissen wie ihr das anstellt, für mehrere Datenbanken in einem Programm zu proggen. Ich lehrne gerne!!!

Zitat:

Und da ich sehr viel SQL direkt in Delphi progge wird das bei mir auf jeden Fall unmöglich. Aber ich lass mich gerne eines besseren belehren. Es kann natürlich auch sein, dass mein Programmierstiel schlecht ist

ersteres stimmt nicht, zweiteres kann sein.

Du solltest den SQL COde separieren, also nicht direkt immer in den Code reinhauen sondern dafür eine eigene Unit drin haben in der nur die SQL Statements als Funktionen bzw. Klasse drin stehen. Diese kannste dann recht schnell udn einfach 'clonen' und für die andere DB anpassen, falls notig. Naja und beim Programmstart prüfste einfach welche DB benutzt wird und daraufhin rufste eben die richtigen Funktionen auf. Dadurch bleibt dein Programm leicht erweiterbar und du musst dich nicht immer durch den ganzen COde wurschteln und ihn dort erweitern wo gerade SQL benuttz wird.

Wer kann mir denn bei folgenden helfen. Ich hab in ACCESS ein Feld als Boolean deklariert. Nehmen wir einmal an das Feld heißt BO. Die Abfrage "select * from ??? where BO" funktioniert. Wenn ich die ganze Gaudi auf MSSQL portiere gibt´s da aber keinen Boolean und das Feld wird in ein Bit-Feld umgewandelt. Der SQL-Text wird nicht akzeptiert und ich muß alles umschreiben.

(Natürlich kann ich ein Funktion SQLBool basteln die "true" bzw. "1" zurück gibt und in den SQL Befehl stopfen "where BO=" + SQLBool(true|false) aber genau das will ich ja nicht.

Lustig wird dann erst wenn man mit "select a.*, b.* from ??? a, ??? b" arbeitet. Weiß jemand wie man hier vernünftig arbeiten kann ?

Es ist tatsächlich so, dass alle "großen" Datenbanken weniger Spezialitäten bieten, als Access. Das hat aber auch einen guten Grund - diese Extras verbraten relativ viel Leistung, was bei einer Anwendung, auf welche viele Benutzer gleichzeitig zugreifen, den Server überlasten könnte.

Boolean-Felder kannst Du dir nicht nur bei SQL-Server, sondern auch bei Oracle usw. abschminken. Es gibt hier leider keine andere Möglichkeit, als ein Feld mit 0 und 1 zu verwenden.
Mit select a.* from tabelle a haben große Datenbanksysteme auch ihre Probleme. Es ist aber gerade bei Mehrbenutzeranwendungen IMMER empfehlenswert, die Felder explizit anzugeben, dann gibt es keine Schwierigkeiten.

@Alfons

Dieser typische Code

funktioniert z.B. bei Access aber bei MS-SQL nicht.
Da darf man anscheinend keine 2 Felder selektieren, die den gleichen Namen haben. Da muß man dann schreiben



und so zieht sich daß durch alle SQL-Anweisungen.

Da kriegst die Krise,