7
SQL Datenbank exportieren
Umstellung einer Verwaltungssoftware auf SQL-Version
Win 2003 Server
Hallo zusammen,
bei uns wurde die bestehende Verwaltungssoftware durch eine SQL-Version ersetzt.
Vor der Umstellung lief die Software mit einer Access Datenbank mit "offener Struktur" und man konnte bestimmte Datenbanken für seine Zwecke kopieren oder in andere Datenbanken exportieren und dort weiterverarbeiten
Jetzt zum Problem: Die Softwareschmiede will mir den Ort der SQL-Dateien auf meinem Server nicht nennen, auch mit dem SQL Managementtool "sehe" ich die Dateien nicht. Allerdings bin auch alles andere als ein SQL Experte.... !
Vermutlich kann man die Dateien ja auch passwort verschlüsseln, vielleicht ein Grund, dass ich mit dem Manager nix anstellen kann.
Grundsätzlich sehe ich ja ein, dass ein Hersteller nicht möchte, dass alle Kunden in der datenbank rumwerkeln, aber ich möchte ja wirklich nur eine Datei kopieren und für einen bestimmten Zweck weiterverarbeiten.
Vom Ablauf her ist es so, dass eine Clientanwendung gestartet wird, die dann auf die SQL-Dateien auf dem Server zugreift.
Vielleicht hat ja jemand eine Idee.
bei uns wurde die bestehende Verwaltungssoftware durch eine SQL-Version ersetzt.
Vor der Umstellung lief die Software mit einer Access Datenbank mit "offener Struktur" und man konnte bestimmte Datenbanken für seine Zwecke kopieren oder in andere Datenbanken exportieren und dort weiterverarbeiten
Jetzt zum Problem: Die Softwareschmiede will mir den Ort der SQL-Dateien auf meinem Server nicht nennen, auch mit dem SQL Managementtool "sehe" ich die Dateien nicht. Allerdings bin auch alles andere als ein SQL Experte.... !
Vermutlich kann man die Dateien ja auch passwort verschlüsseln, vielleicht ein Grund, dass ich mit dem Manager nix anstellen kann.
Grundsätzlich sehe ich ja ein, dass ein Hersteller nicht möchte, dass alle Kunden in der datenbank rumwerkeln, aber ich möchte ja wirklich nur eine Datei kopieren und für einen bestimmten Zweck weiterverarbeiten.
Vom Ablauf her ist es so, dass eine Clientanwendung gestartet wird, die dann auf die SQL-Dateien auf dem Server zugreift.
Vielleicht hat ja jemand eine Idee.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 148884
Url: https://administrator.de/contentid/148884
Printed on: April 26, 2024 at 03:04 o'clock
7 Comments
Latest comment
Moin,
ja, ich habe eine Idee: LASS DIE FINGER DAVON! Wenn du nichts über Datenbanken weisst ist das nen guter Grund um nicht an der Produktions-DB zu spielen! Dort gibt es kein Undo - also nen Fehler und du hast nen Problem...
Und da es auch noch mehrere Optionen gibt (MySQL, MS-SQL oder z.B. nen Access per ODBC usw...) kann man das eh so generell nicht sagen...
Gruß
Mike
ja, ich habe eine Idee: LASS DIE FINGER DAVON! Wenn du nichts über Datenbanken weisst ist das nen guter Grund um nicht an der Produktions-DB zu spielen! Dort gibt es kein Undo - also nen Fehler und du hast nen Problem...
Und da es auch noch mehrere Optionen gibt (MySQL, MS-SQL oder z.B. nen Access per ODBC usw...) kann man das eh so generell nicht sagen...
Gruß
Mike
Hallo zahni,
ich finde die Frage nicht.
Grüße, Steffen
ich finde die Frage nicht.
Grüße, Steffen
HI,
wurde die SW speziell für Euch entwickelt? Wenn nein, sieht es schlecht aus! Sonst hätte man auf bestimmte Features ggf. Einfluß nehmen können.
Was für Daten willst du überhaupt haben? Bietet evtl. der Hersteller eine Erweiterung an, damit die Daten weiterverarbeitet werden können? Nicht ohne Grund schieben die meisten Hersteller da einen Riegel vor. Die wollen halt Geld verdienen..... Wenn du mit den Features nicht zufrieden bist, kannst du ggf. die SW erweitern. Oder Du musst dir einen anderen Hersteller suchen! Ist nur alles eine kostenfrage. Du/ Ihr wollt so wenig wie möglich ausgeben. Die Firmen verfolgen ein anderes Ziel.....
Du kannst vermutlich lange suchen. Und wenn du fündig wirst, ist die DB ggf. nicht zu gebrauchen, da nur mit der SW verwendbar....
mfg Crusher
wurde die SW speziell für Euch entwickelt? Wenn nein, sieht es schlecht aus! Sonst hätte man auf bestimmte Features ggf. Einfluß nehmen können.
Was für Daten willst du überhaupt haben? Bietet evtl. der Hersteller eine Erweiterung an, damit die Daten weiterverarbeitet werden können? Nicht ohne Grund schieben die meisten Hersteller da einen Riegel vor. Die wollen halt Geld verdienen..... Wenn du mit den Features nicht zufrieden bist, kannst du ggf. die SW erweitern. Oder Du musst dir einen anderen Hersteller suchen! Ist nur alles eine kostenfrage. Du/ Ihr wollt so wenig wie möglich ausgeben. Die Firmen verfolgen ein anderes Ziel.....
Du kannst vermutlich lange suchen. Und wenn du fündig wirst, ist die DB ggf. nicht zu gebrauchen, da nur mit der SW verwendbar....
mfg Crusher
Hi nochmal,
möchte doch noch mal einen kurzen Kommentar zu den leider zum Teil nicht sehr konstruktiven Antworten schreiben:
Bin zwar wie gesagt kein grosser DB-Experte, aber ein ganz passabler C-Programmierer und habe deshalb noch jede Datenbank (ob SQL, Informix C-Isam etc.) nach meinen Wünschen ausgewertet.
Zu den gut gemeinten Ratschlägen bzgl. der Softwareerweiterungen kann ich nur sagen, dass ICH die Entwicklungskosten von 240€ + Steuer bezahle, bin auf keinem Amt beschäftigt und die Krankenkasse zahlts ausnahmsweise mal auch nicht.
Und eine bestehende DB zu kopieren birgt sicher auch nicht das größte Risiko für DB-Inkonsistenten, und wenn doch zahle ich ja wie oben schon erwähnt die Kosten ....
@Crusher: warum eine hundsnormale SQL-DB nur mit der bestehenden SW zu gebrauchen sein soll, ist mit auch nicht so recht klar.
Grüße
möchte doch noch mal einen kurzen Kommentar zu den leider zum Teil nicht sehr konstruktiven Antworten schreiben:
Bin zwar wie gesagt kein grosser DB-Experte, aber ein ganz passabler C-Programmierer und habe deshalb noch jede Datenbank (ob SQL, Informix C-Isam etc.) nach meinen Wünschen ausgewertet.
Zu den gut gemeinten Ratschlägen bzgl. der Softwareerweiterungen kann ich nur sagen, dass ICH die Entwicklungskosten von 240€ + Steuer bezahle, bin auf keinem Amt beschäftigt und die Krankenkasse zahlts ausnahmsweise mal auch nicht.
Und eine bestehende DB zu kopieren birgt sicher auch nicht das größte Risiko für DB-Inkonsistenten, und wenn doch zahle ich ja wie oben schon erwähnt die Kosten ....
@Crusher: warum eine hundsnormale SQL-DB nur mit der bestehenden SW zu gebrauchen sein soll, ist mit auch nicht so recht klar.
Grüße
Moin zahni,
ich verstehe dein inhaltliches Anliegen (denke ich).
Den Lösungsweg, der dir vorschwebt.... da wiederum verstehe ich die Zurückhaltung der Softwareschmiede.
Über das Thema könnte ich ein paar längere Ausführungen schreiben und gern Herleitungen nachliefern.. erspar ich uns allen.
Auf den Punkt gebracht das Ergebnis:
--> Lösung für beide Seiten
Von was für Dimensionen reden wir denn hier (Anzahl Entities, Anzahl Datensätze, MByte/GByte/TByte-Größenordnungen)?
Wenn es vorher unter Access gelaufen ist und die ganze Implementierung gerade mal soviel gekostet hat wie ein Zug um die Häuser mit meinen PraktikantInnen... das kann ja nicht sooo gigantisch sein.
Grüße
Biber
ich verstehe dein inhaltliches Anliegen (denke ich).
Den Lösungsweg, der dir vorschwebt.... da wiederum verstehe ich die Zurückhaltung der Softwareschmiede.
Über das Thema könnte ich ein paar längere Ausführungen schreiben und gern Herleitungen nachliefern.. erspar ich uns allen.
Auf den Punkt gebracht das Ergebnis:
- Persistenzschicht/Physische Implementierung der Datenbank/der Tabellen == 100%ig bei der Softwareklitsche, solange das logisch/fachliche Modell damit umgesetzt wird. Auf deutscher: Braucht dich nicht zu interessieren, geht dich nichts an.
- Logisch/fachliche Ebene - die ist allerdings dein Ding.
--> Lösung für beide Seiten
- (recommended) du lässt dir für die relevanten fachlichen Daten, die du sehen/weiterverarbeiten willst einen (oder mehrere Views) zusammenstellen - du benennst dafür alle relevanten fachlichen Felder (business names), die Spaltenreihenfolge, ggf Sortierung und Umfang, falls nicht "alle" Datensätze verarbeitungsrelevant für dich sind. Und einen nur lesenden Zugriff. Hast du kein Problem mit und die Jungs und Mädel der SW-Klitsche auch nicht.
- (variierte Krücke, not recommended): wie oben, aber nicht für den "online"/Livezugriff, sondern als täglich/wöchentlich/auf Anforderung erzeugtes Flatfile (Fixed Lenght, Excel, CSV, XML,...) zur maschinellen Verarbeitung auf einen Server/Share deiner Wahl.
Von was für Dimensionen reden wir denn hier (Anzahl Entities, Anzahl Datensätze, MByte/GByte/TByte-Größenordnungen)?
Wenn es vorher unter Access gelaufen ist und die ganze Implementierung gerade mal soviel gekostet hat wie ein Zug um die Häuser mit meinen PraktikantInnen... das kann ja nicht sooo gigantisch sein.
Grüße
Biber
Hi !
Mensch, immer wenn den Leuten die Antworten nicht gefallen, sind sie auch immer gleich nicht konstruktiv...Wir sind hier in einem Forum, da darf jeder seine Meinung schreiben, sofern sie niemanden beleidigt und nicht gegen Forenregeln verstösst....
Und wenn Du sämtliche Programmiersprachen und Tools in einen Topf haust und kräftig drin herumrührst, hat der Hersteller der Software die Datenbank absichtlich "dicht gemacht", kommst Du legal nicht an die Daten (ausser Du "bewegst" dich auf dem "nicht administrativen Niveau" und da wärst Du in diesem Forum komplett falsch) und das sollte man als passabler C Programmierer eigentlich wissen. Warum hast Du das, als so guter Fachmann, nicht schon vorab und ganz offiziell mit der Herstellerfirma geklärt? Wurde die Umstellung der Software nicht mit den IT-Leuten (firmeneigene Entwickler oder Admins) besprochen?
Weil das der Hersteller eurer Software offenbar genau so will und da wirst dich wohl auch mit denen auseinandersetzen müssen. Und wenn ich ganz ehrlich bin, würde mir das auch nicht gefallen, wenn ein Kunde in "meiner" Datenbank herumpatcht. Das Problem solltest Du also besser mit dem Hersteller der Software besprechen oder im Notfall eben offizielle Schnittstellen in deren Software bzw. der Datenbank fordern, als auf unsere nicht konstruktiven Antworten zu setzen.
mrtux
Zitat von @zahni:
möchte doch noch mal einen kurzen Kommentar zu den leider zum Teil nicht sehr konstruktiven Antworten schreiben:
möchte doch noch mal einen kurzen Kommentar zu den leider zum Teil nicht sehr konstruktiven Antworten schreiben:
Mensch, immer wenn den Leuten die Antworten nicht gefallen, sind sie auch immer gleich nicht konstruktiv...Wir sind hier in einem Forum, da darf jeder seine Meinung schreiben, sofern sie niemanden beleidigt und nicht gegen Forenregeln verstösst....
Bin zwar wie gesagt kein grosser DB-Experte, aber ein ganz passabler C-Programmierer und habe deshalb noch jede Datenbank
Und wenn Du sämtliche Programmiersprachen und Tools in einen Topf haust und kräftig drin herumrührst, hat der Hersteller der Software die Datenbank absichtlich "dicht gemacht", kommst Du legal nicht an die Daten (ausser Du "bewegst" dich auf dem "nicht administrativen Niveau" und da wärst Du in diesem Forum komplett falsch) und das sollte man als passabler C Programmierer eigentlich wissen. Warum hast Du das, als so guter Fachmann, nicht schon vorab und ganz offiziell mit der Herstellerfirma geklärt? Wurde die Umstellung der Software nicht mit den IT-Leuten (firmeneigene Entwickler oder Admins) besprochen?
@Crusher: warum eine hundsnormale SQL-DB nur mit der bestehenden SW zu gebrauchen sein soll, ist mit auch nicht so recht klar.
Weil das der Hersteller eurer Software offenbar genau so will und da wirst dich wohl auch mit denen auseinandersetzen müssen. Und wenn ich ganz ehrlich bin, würde mir das auch nicht gefallen, wenn ein Kunde in "meiner" Datenbank herumpatcht. Das Problem solltest Du also besser mit dem Hersteller der Software besprechen oder im Notfall eben offizielle Schnittstellen in deren Software bzw. der Datenbank fordern, als auf unsere nicht konstruktiven Antworten zu setzen.
mrtux
Also nochmal zur Klarstellung und dann können wir es auch gerne dabei belassen.
1. Klar kann jeder schreiben was er will, aber ich kann ja trotzdem für mich entscheiden, ob das meiner Meinung nach konstruktiv ist oder nicht. Hat nix damit zu tun, ob mir die Antwort gefällt.
2. Bei der Software handelt es sich um ein komplettes Paket für Arztpraxen, die sind zu 99,99% von der Stange, da gibt es keine Individualisierungen, weil die Versionspflege angeblich zu aufwändig wird.
Gibt auch nicht soviele Softwarehäuser für solche Nischenprodukte.
Und da kann man \"Fachmann\" sein wie man will, von Seiten der Anbieter heisst es einfach, ab jetzt wird die Software auf xy umgestellt und die bestehenden Versionen nicht mehr gepflegt. Da es aber gerade im Gesundheitswesen alle Nase lang Änderungen gibt, die durch Updates in der Software abgebildet werden müssen, ist man halt auf den Anbieter irgendwie doch angewiesen wenn man nicht alle 6 Monate die Software wechseln will. Und ich spreche hier über Lizenzen im 5-Stelligen €-Bereich, mrtux!
3. Kurz nochmal zu dem was ich will und nicht will: Niemand will in einer Produktions-DB \"rumpatchen\"! Vor der Umstellung gab es access-Dateien, die ich mir 1 x Monat !!kopiert!! habe, um sie anschlissend nach dem Motto \"Welche OP-Methode hatte die kürzeste Verweilzeit im KH mit der kürzesten Nachbehandlung und den wenigsten Komplikationen postoperativ\" o.ä. Diese Art Abfragen würde ich auch gerne weiterhin bei den SQL-Dateien vornehmen, dazu müsste ich aber wissen wo Sie auf dem Server liegen. That\'s all!
Also weder besonders schwierig (wenn man Zugriff auf die kopierten Daten hat), noch besonders kritisch, da ich ja nur auf Kopien arbeiten möchte.
Grüße
1. Klar kann jeder schreiben was er will, aber ich kann ja trotzdem für mich entscheiden, ob das meiner Meinung nach konstruktiv ist oder nicht. Hat nix damit zu tun, ob mir die Antwort gefällt.
2. Bei der Software handelt es sich um ein komplettes Paket für Arztpraxen, die sind zu 99,99% von der Stange, da gibt es keine Individualisierungen, weil die Versionspflege angeblich zu aufwändig wird.
Gibt auch nicht soviele Softwarehäuser für solche Nischenprodukte.
Und da kann man \"Fachmann\" sein wie man will, von Seiten der Anbieter heisst es einfach, ab jetzt wird die Software auf xy umgestellt und die bestehenden Versionen nicht mehr gepflegt. Da es aber gerade im Gesundheitswesen alle Nase lang Änderungen gibt, die durch Updates in der Software abgebildet werden müssen, ist man halt auf den Anbieter irgendwie doch angewiesen wenn man nicht alle 6 Monate die Software wechseln will. Und ich spreche hier über Lizenzen im 5-Stelligen €-Bereich, mrtux!
3. Kurz nochmal zu dem was ich will und nicht will: Niemand will in einer Produktions-DB \"rumpatchen\"! Vor der Umstellung gab es access-Dateien, die ich mir 1 x Monat !!kopiert!! habe, um sie anschlissend nach dem Motto \"Welche OP-Methode hatte die kürzeste Verweilzeit im KH mit der kürzesten Nachbehandlung und den wenigsten Komplikationen postoperativ\" o.ä. Diese Art Abfragen würde ich auch gerne weiterhin bei den SQL-Dateien vornehmen, dazu müsste ich aber wissen wo Sie auf dem Server liegen. That\'s all!
Also weder besonders schwierig (wenn man Zugriff auf die kopierten Daten hat), noch besonders kritisch, da ich ja nur auf Kopien arbeiten möchte.
Grüße
