Zugriffsmöglichkeiten unter MS-SQL-Server (Express) auf andere Datenbank?

muemmel

Hi Linnea und Hustbaer,

vielen Dank für Eure Antworten.
Leider ist es aber so, das die Methode mit gemeinsamen Server nicht geht. (wäre ja auch zu einfach).
Das ganze kann nur mit einem lokalen Server laufen, da die einzelnen Rehner nicht am Netz sind. Die können nur regelmäßig die neuen Daten auf einer CD oder Stick übergeben/zugeschickt bekommen, und dann muss der Rest mehr oder weniger automatisch gehen. Bei Paradox wie bisher kein Problem, einfach drüber kopieren.
Bei Access auch kein Problem, entweder drüber kopieren oder mit select into mit Datenbankangabe rüberholen.
Aber sowohl Paradox als auch Access sind nun mal keine richtigen Datenbanksysteme sondern eher Datenspeicher.
Sicher ist es machbar, die Daten auch aus einer mdb zu lesen und mittels Quelltext zu der SQL-Datenbank rüberzuschieben. Oder man nimmt alle Änderungen generell durch Queltext vor (SQL-Script oder Delphi- bzw. C++Quelltext). Aber das erscheint mir ein wenig aufwendig wenn man komplette Dateien mit vielleicht hunderten Datensätzen über Scripte nachpflegt.
Server Management Studio ist leider wegen fehlender Kenntnisse beim Nutzer nicht gangbar.

Gruß Mümmel

Linnea

In diesem Fall solltet ihr bei Access/Paradox bleiben. Sonst müßte auf jedem Rechner das DBMS installiert werden ohne einen wirklichen Mehrwert darzustellen (außer Speicherplatz und Arbeitspeicher für die hinzugekommenen Dienste).
Die Fehlerquellen für das Starten/Stoppen des Dienstes, das An-/Abhängen der Datenbank oder durch unterschiedliche Einstellungen bei der Installation des DBMS sind deutlich höher wie beim einfachen Kopieren einer Access-Datenbank.

Falls die Rechner zwar nicht miteinander aber trotzdem mit dem Internet verbunden sein sollten, könnte man noch über einen externen Mietserver eine Variante mit Web-Interface in Betracht ziehen. Aber das ist wahrscheinlich etwas zu viel des Guten

muemmel

Hi Linnea,

vielen Dank für Deine klare Ansage. Das ist doch zumindest erst mal ne Hausnummer mit der man arbeiten kann.
Trotzdem noch ne Frage an Dich:
Hast du irgend eine Ahnung, wie es mit der Leistungsfähigkeit zwischen Access und MS-SQL-Server aussieht, wieviel mal Access da langsamer ist (Hauptsächlich Select und Joins). Gewänne man mit einem "richtigen" SQL-Server wirklich so viel an Mehrleistung, oder bleibt das irgendwie in noch einigermaßen vergleichbarem Rahmen (bei identischer Hardware und SQL-Server auf der gleichen Maschine wie Nutzprozess) Wegen 30 oder 50% Mehrleistung muss man da wirklich nicht hinterherrennen, sondern besser in Hardware investierern.

Gruß Mümmel

Zeus

Ich hab nun nicht alles gelesen, aber man kann Microsoft SQL Server Database File nutzen, die die Datenbank als MDF speichert.

Linnea

Was von beiden schneller ist hängt zum einen ab von der Datenmenge die enthalten ist und zum anderen von der Datenmenge die abgefragt wird. Es kommt auch drauf an ob Indiezes gesetzt sind oder nicht. Außerdem kann auch das Front-End ein Nadelöhr beinhalten, wenn z.B. der Aufbau der Anzeige der Daten lange dauert. Oder die Verknüfung des Front-End zur Datenbank (ODBC, BDE...) ist nicht die Beste. Also alles in allem viele Kriterien.

Für die Datenbankoptimierung bietet MSSQL natürlich einige Möglichkeiten, z.b: Anzeige des Ausführungplans oder auch die Auflistung fehlender Indiezes, als Hilfestellung zur Erstellung von Indiezes.

Bei Access gibt es über das Menu "Extras" > "Datenbank-Dienstprogramme" > "Datenbank komprimieren und reparieren.." die Möglichkeit die Access-Datenbank/Datei zu verkleinern und damit unnötigen Speicherplatz freizugeben.
Als kleines Beispiel: letztens hatte ich eine 1,6 GB MDE-Access-Datei (kompilierte MDB-Access-Datei) von einem Kunden mal komprimiert und danach war die Datei nur noch 11 MB groß

Normalerweise sind für größere Datenmengen aber die DBMS meist schneller.
Wie das in eurem Fall ist müßte man halt mal ausprobieren.

muemmel

Hi Linnea,

da es, wie ich aus Deinen Ausführungen schließe, eben doch beim Umstieg von Access auf DBMS nicht so ist, als ob man vom Anlasser auf die Turbine umschaltet, denke ich, dass ich mit den Leistungen von Access leben kann.

Ein Riesenvorteil bei Access ist ja, das für die Nutzung über ADO wirklich überhauptn nichts installiert werden muss. Programm aufspielen, starten und los.
Was schade ist, aber eben nicht zu ändern ist die Tatsache, das Access keine echten mehrzeiligen Prozeduren hat. Aber das kann man ja in der eigentlihcen Anwendungssprache machen.

Ein Problem habe ich aber noch in Access unter Ado. Wenn ich in einem AdoTable (Delphi bzw. C++Builder) Feldwerte ändere, dann wird in den meisten Fällen beim posten nicht der richtige Datensatz erkannt und ich bekomme eine Fehlermeldung, so dass ich da jetzt schon davon abgehe außer bei Insert Post zu verweden sondern die Änderungen verwerfe, sie mit einem SQL-Befehl eintrage und die Datei mit Requery neu öffne. Übrigens trotz eingestelltem eindeutigem Index. Hast Du da noch einen Tip? Bei DAO-Zugriffen (mit Kadao) ist mir das nie passiert.

Gruß Mümmel

Linnea

Da kann ich dir nicht wirklich weiterhelfen. Ich verwende nur TADOCommand und TADODataSet und nehmen immer die SQL-Befehle.
Gibts zu dem Problem schon einen Thread? Die Fehlermeldung wär zur Problemfindung schon hilfreich

Irgendwo stand mal, daß ADOQuery und ADOTable nur als Übergangshilfe von BDE zu ADO zu verwenden sind, ansonsten aber eigentlich ziemlich buggy sein sollen...

muemmel

Hi Linnea,

hier die Fehlermeldung:
Die zum Aktualisieren angegebene Zeile wurde nicht gefunden. Einge Werte wurden seit dem letzten Lesen ggf. geändert.
Wenn man Google anschmeist, ist das fast sowas wie eine ADO-Standardmeldung. Nur bin ich mit den verschiedenen Tips nicht zu Rande gekommen. Der Fehler ist hartneckig. Was nichit heist, dass er zuverlässig wäre. Mal kommt er und mal nicht. aber ich habe eben mal probiert, TADODataSet könnte funktionieren.

Was ich bei ADO vermisse ist sowas wie TUpdateSQL, wo man die Updateansweisung selber angeben kann, denn meine Version ist doch ziemlich am System vorbei gemogelt.

Wenn Du immer SQL-Befehle nimmst, wie machst Du es da bei Eingabefeldern? Nimmst Du da keine DBEdit-Felder? Schreibst Du das in normale Editfelder und dann per SQL zurück?
Und noch ne Frage, verwendest Du TADODataSet direkt, oder über den Umweg TClientdataset?

Ich hoffe ich nerve dich nicht zu sehr.

Gruß Mümmel

Linnea

Meist verwende ich wirklich nur TADOCommand für alles was nicht mit "Select" zu tun hat. Im Zusammenhang mit TADODataset wenn ich eine Datenbankabfrage mit "Select" mache. Dazu gibts bestimmt auch einige Beiträge von mir im BCB-Unterforum.

Da ich in letzter Zeit eher WEB-Anwendungen programmiert hab, brauchte ich keine TDB*-Komponenten. Für kleinere Sachen hab ich dann aber meist schnell eine ComboBox oder andere Elemente mit den Daten aus der Abfrage gefüllt und für weitere Datenbankabfrage wieder verwendet. Ansonsten nutze ich noch TDBGrid und TDBChart.

Für größere Eingabemasken oder Datenbankanzeigen mit vielen Feldern und einem DBNavigator sind aber die TDB*-Komponenten wahrscheinlich sinnvoll. Im Prinzip müßte das aber auch mit einem TADODataSet möglich sein. Man kann z.B. über die Eigenschaft CommandType auch angeben, daß das DataSet eine Tabelle ist und somit sollten Änderungen (z.b. mit Hilfe des DBNavigators) auch möglich sein.

muemmel

Hi Linnea,

ja, das mit dem TADODataset scheint wirklihc besser zu funktionieren. Jedengfalls konnte ich den Fehler auf Anhieb erst mal nicht wieder provozieren. (wird wenn überhaupt bestimmt bei einem Kunden auftreten).
Die einfachen Lösungen gehen leider bei mir nicht. Im aktuellen Programm hab ich eine Tabelle mti ca 140 einezelnen Datenfeldern, in die überall was reingeschrieben werden muss, bzw. die auch geändert werden können müssen. Außerdem sind sie (zumindest ein Teil davon) in einem Grid anzuzeigen.
Klar, jetzt kann wieder einer sagen, wenn so viele einzelne Felder zu bearbeiten sind, dann kann am Konzept was nciht stimmen. Hatter ja recht, stimmt wirklich manches nicht, aber die Datenbankstruktur ist fest und ich muss damit leben.
Eventuell bin ich am überlegen, ob ich das DBGrid und die DBEdits.... trenne, und im Grid ale Datensätze anzeige, und fürs bearbeiten in den DBEdits und Combos... jeweils immer nur einen einzigen Datensatz per select aufrufe. Fürs Einfügen müsste ich dann eben einen nicht vorhandenen Datendatz (z.B. mit ID = -1 oder ID = max( ID ) + 1 ) "aufrufen" und mit Insert dranhängen.

Gruß Mümmel