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

Linnea

Das mit dem Beenden des Server-Prozesses ist beim MSSQL auch möglich, aber auch nicht umbedingt sinnvoll. Irgendwie arbeitet das an der eigentlichen Datenbankgeschichte vorbei. Außerdem gibt es bei MSSQL noch eine zugehörige LDF-Datei und die müßte dann auch mit kopiert werden. Was passiert wenn der Prozess nicht mehr startet? Braucht ihr dann wieder die Adminna? Könnt ihr ohne Admin den Prozess so einfach beenden? Vor allem wenn der MSSQL-Server auf einem anderen Rechner liegt? usw...

Wenn ihr eh schon ein Front-End für die Endbenutzer habt warum vereinfacht ihr dann nicht die Datenbank-/Tabellenstruktur?
Die Fragen sind also z.B:
Wer legt welche Daten wie in welche Tabellen?
Wer greift auf welche Daten wie zu?
Wie sind die Daten miteinander verknüpft?

Im Prinzip wäre einen Lösung so vorstellbar (grobes Konzept ohne nähere Kenntnis der Antworten zu den gerade genannten Fragen):
Irgendwo in der Firma steht ein Rechner mit nem MSSQL-Server und mindestens einer Datenbank. Die einen Mitarbeiter (Gruppe 1) können mittels eines Front-End Daten in die einige Tabellen eintragen und ändern, andere Daten aber nur anschauen bzw. für Berechnungen verwenden. Andere Mitarbeiter (Gruppe 2) können die Daten, die Gruppe 1 nur anschauen kann, bearbeiten, erstellen und löschen. Auch dies geschieht über ein Front-End welches auch das Gleiche wie für Gruppe 1 sein kann. Man muß halt nur über z.B. ein Login die Rechte für bestimmte Tabellen/Ansichten abfragen bzw. vergeben.

Dazu muß man natürlich ein Front-End zur Verfügung stellen was alle notwendigen Datenbankoperationen beinhaltet. Schließlich sollte kein Mitarbeiter direkt an der Datenbank arbeiten. Durch das Front-End ist es aber auch für die Mitarbeiter egal wie die Datenbank aufgebaut ist.

Ich hab für eine Firma ein Auftragsverwaltungsprogramm mit dem BCB und Interbase auf ähnliche Weise umgesetzt.

hustbaer

Ich denke auch dass es besser wäre auf das Rumkopieren von Datenbank-Files zu verzichten.
Was Linnea schreibt klingt IMO vernünftig.

SQL-Server wird auf einem PC (Server) installiert. Alle Daten liegen auf diesem einen Server. Idealerweise in einer einzigen Datenbank, denn Dinge wie Referential-Integrity-Constraints funktionieren nur innerhalb einer Datenbank.
(Mehrere getrennte Datenbanken kann in bestimmten Fällen Sinn machen, aber die sich dadurch ergebenden Nachteile sollte man nicht ohne guten Grund in Kauf nehmen).

Der Zugriff auf die Datenbank erfolgt übers Netz, d.h. die Client-Applikation läuft auf dem PC des jeweiligen Mitarbeiters.

So lange nicht offline mit den Daten gearbeitet werden muss, ist das vermutlich die beste Lösung.

In dieser einen Datenbank legst du dann mehrere Tabellen an.
Einmal die Paramerter-Tabellen, die Daten/Parameter enthalten die für alle User gemeinsam gelten.
Und dann die User-Tabellen.

Bei denen kannst du zwei verschiedene Varianten machen:

Jeder User bekommt seine eigenen Tabellen. Dazu kann man z.B. auch am SQL-Server verschiedene SQL-User anlegen, und jeder SQL-User hat z.B. seinen eigenen "foo" Table. Der vom Franz heisst dann "franz.foo" und der von der Susi heisst "susi.foo".
Die Daten von allen Usern werden in einem einzigen "foo" Table gespeichert, der eine UserID Spalte enthält.

Ohne weitere Informationen würde ich tendenziell eher Variante (2) empfehlen, wobei es vermutlich auch gute Gründe für Variante (1) geben wird.

Was die Verwaltung der "Parameter-Daten" angeht sehe ich das etwas anders als Linnea. IMO ist es in vielen Situationen vollkommen OK, wenn man das einfach über das SQL Server Management Studio macht. Vorausgesetzt die Mitarbeiter die das machen kennen sich halbwegs mit SQL Server aus. Wenn man nicht gleich mit einem SQL-Admin Account einsteigt, kann man über Berechtigungen im SQL Server auch halbwegs gut kontrollieren was bestimmte User machen dürfen und was nicht. Die bereits erwähnten Referential-Integrity-Constraints helfen auch mit hier Unfälle zu vermeiden.

Wenn an diesen Daten natürlich Leute ohne jegliche SQL-Server Kenntnisse arbeiten müssen, oder aber man sehr häufig Änderungen an diesen Daten macht, dann wäre vermutlich wirklich ein eigenes Frontend besser.

----

ps:
Falls die User doch offline arbeite können müssen (also z.b. von zu Hause aus, ohne VPN Tunnel in die Firma), wird leider alles etwas (deutlich) komplizierter.
In dem Fall könnte man sich evtl. auch überlegen ein Web-Interface zu verwenden.

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