Daten von Access nach MSSQL kopieren

[Brinkman]

Hallo zusammen,

es exisitiert eine kleine Anwendung mit Daten auf ACCESS bzw. MSSQL. Es gibt un Kunden, die nun auf MSSQL migrieren möchten.
Wie ist nun die einfachste Möglichkeit - von mir aus auch per batch - die Daten aus der ACCESS-DB in eine existierende , aber leere SQL-DB zu kopieren? Ich würde ungerne die Daten Feldweise von ACCESS nach SQL bewegen, da die Datenstruktur häufig erweitert wird und somit die Konvertierungsprozedur entsprechend nachgezogen werden müsste.

Beste Grüße und vielen Dank für kreative Ideen
BrinkMan

[mkinzler]

Was meinst du mit feldweise?

[omata]

Innerhalb von Access kann man in der Tabellenansicht jede Tabelle exportieren. Das Exportieren erfolgt über einen DSN-Eintrag in der ODBC-Administration und schon sind die Tabellen auf dem MSSQL-Server.

Edit: Ich habe jetzt nochmal genau nachgesehen (Access 2007):

Tabellenansicht, Rechte Maus auf die zu exportierende Tabelle, Exportieren, ODBC-Datenbank, OK, Computerdatenquellen, System-DSN auswählen (der muss genug Berechtigung auf dem MSSQL-Server haben)

[Brinkman]

@mkinzler:
War eventuell ein wenig missverständlich,
da sich die Datenstruktur häufig ändert, möchte ich bei der Migration nicht erst die Datenstruktur von Access in SQL nachbilden (ist sicherlich fehleranfällig) und dann per INSERT alle Datensätze übertragen sondern am liebsten die Tabellen komplett mit der Tabellenbeschreibung in einem Rutsch inkl. Abhängigkeiten übertragen. Oder gar die ganze Access-DB als würde ich den Import-Assi nutzen, nur halt eben von DELPHI aus.

@omata:
Das wäre der einfachste Weg, allerdings ist die Access-DB verschlüsselt und mit Passwort geschützt, der Kunde hat u.U. keine Access-Umgebung und soll das Passwort wenn möglich auch nicht bekommen und die administrative Kenntnis (das zeigt die Erfahrung) ist nicht unbedingt immer sehr hoch. Anleitungen in Bild und Text reichen teilweise für einfache Dinge nicht.

[omata]

Ok, das macht Sinn.

Was für eine Access-Datei (Version) liegt denn vor?
Und soll die Tabellenstruktur auf dem SQL-Server auch wieder passwort-geschützt sein? Oder ist dort dann alles offen?

[Bummi]

Per SQL über AddLinkedServer(Login) und dann Select * into nn from ann

[Brinkman]

@omata: Nein, die Tabellen können da offen sein. Access-Datei ist in Version 2003

@Bummi: Per SQL hört sich an wie auf dem Management-Studio, oder? Ich würde dies lieber direkt vom DELPHI-Programm aus machen wollen...

[omata]

Die Idde von Bummi ist doch sehr gut.

Ich würde über dein Delphi-Programm einen Verbindungsserver innerhalb des SQL-Servers einrichten, der die Access-Datei einbindet. Da du deine SQL-Tabellenstruktur kennst, kannst du diese über dein Delphi-Programm auf dem SQL-Server erzeugen und dann die Tabelleninhalte in der richtigen Reihenfolge nacheinander durch INSERT INTO + SELECT-Anweisungen aus dem Verbindungsserver in den SQL-Server kopieren lassen. Zum Schluss wird dann der Verbindungsserver wieder gelöscht.

1. sp_addlinkedserver 'AccessVerbindung', 'Access 97', 'Microsoft.Jet.OLEDB.4.0', 'c:\mydata\Access.mdb'
2. SQL-Skript (CREATE TABLES)
3. INSERT-Statements (INSERT INTO tabelle1 SELECT * FROM AccessVerbindung.tabelle1)
4. sp_dropserver 'AccessVerbindung', NULL

[generic]

Kennt ihr den ssma for access?

http://www.microsoft.com/sqlserver/e...ol.aspx#Access

Ist ein Microsoft Programm für das Migrieren.

Blog mit zusätzlichen Informationen:
http://blogs.msdn.com/b/ssma/p/access.aspx

[Brinkman]

@omata: das ist genau das Problem, die Struktur ändert sich zu häufig als dass ich individuell pro Version eine Migration programmieren möchte. Daher sollte es besser ein Import kompletter Tabellen (Struktur und Daten) sein bei dem auch Abhängigkeiten erhalten bleiben. Das ständige Ändern der Datenstrukturen kann ich leider nicht verhindern.

@generic: ssma ist zwar gut, kann ich dem Kunsen aber nicht zumuten.

[Bummi]

@Brinkman

wie sinnvoll min mit einer solchen DB arbeiten kann mußt Du sebst beurteilen, aber Du kannst nach Einbindung des Verbindugsservers per SQL per

Code:

Select * 
into NewTable1
from Verbindungsserver...Tabelle1

Struktur und Daten übernehmen, freilich ohne AutoID's, Indizes, Trigger und Fremdschlüssel
da ist dann wieder "Handarbeit" per SQL nötig

[p80286]

Was verstehst Du unter

Zitat:

Zitat von Brinkman (Beitrag 1174053)

die Struktur ändert sich zu häufig als dass ich individuell pro Version eine Migration programmieren möchte.

Wenn Du z.B. eine Adressdatenbank hast und Deine Versionen würden eine, zwei oder keine Zweitadresse unterstützen, dann wäre es ja ein einfaches dere neuen DB die Möglichkeit für mehrere Zweitadressen zu implementieren.
Ein Problem hättest Du wenn es in der einen Version nur ein Namensfeld und in einer anderen Familienname und Vorname gäbe.

Könntest Du vllt. näher beschreiben welcher Art Dein Problem ist?

Gruß
K-H

Wenn auf den Kundenrechnern kein Access installiert ist, könte das vielleicht weiter helfen.

[Brinkman]

Hallo zusammen,

zuerst einmal vielen Dank für die Antworten!

@Bummi: Ich muss / will mit Autowerten etc. alles übernehmen.

@p80286: Es kommen laufend neue Kundenanforderungen dazu. Um bei Ihrem Beispiel zu bleiben, es gibt nicht nur eine Adresse, sondern der eine möchte cuch einen Skype-Eintrag und der andere einen Facbook-Link. Daher kommt bei vielen Anpassungen für Kunden eine Spalte oder aber auch eine Tabelle dazu. Da es das Programm identisch für SQL und Access gibt, kann theoretisch zu jeder Zeit auch umgeschaltet werden. Manuell habe ich das inzwischen bei einigen Kunden gemacht und läuft auch. Allerdings möchte ich da nicht an spezielle Versionen der Datenstruktur gebunden sein, da die Kunden vermutlich nicht unbedingt ein Update bekommen möchten oder sollen. Aus diesem Grund würde ich gerne die Daten und Strukturen unabhängig von der Datenstruktur übertragen können.

@generic: ich habe mir soeben mal SSMA for Access 5.2 angeschaut. Alles momentan ganz prima, aber er meckert nicht an, dass die Access verschlüsselt ist, fragt aber auch nicht nach einem Passwort. Da muss ich mal schauen, wie es da weitergeht. Außerdem wäre es schön, wenn man dieses Tool eventuell sogar als Kommandozeilenprogramm laiufen lassen könnte bzw. eine Konfigurationsdatei übergeben könnte. Geht dies?

Beste Grüße
Brinkman

[Bummi]

Ein Programm das sich nicht auf dahinterliegende Datenstrukturen verlassen kann ??
Vielleicht solltest Du auf Strukturen wie
[Table_link][TableID][Name][Value] für die ständigen Erweiterungen umstellen, also Daten längs statt Quer verwalten.

[shmia]

Zitat:

Zitat von Brinkman (Beitrag 1174112)

Es kommen laufend neue Kundenanforderungen dazu. ... Daher kommt bei vielen Anpassungen für Kunden eine Spalte oder aber auch eine Tabelle dazu.

Du brauchst ein Programm oder Script, dass eine ältere Datenbank immer auf die aktuelle Datenbankstruktur updatet!

Delphi-Quellcode:

// Pseudocode
if not FieldExists('Adressen', 'Skype') then
   AppendField('Adressen', 'Skype', 'varchar(40)', {Null=}True);

if not TableExists('SubContacts') then
   CreateTable('SubContacts', ['IdSubContact varchar(20) NOT NULL', 'Beschreibung varchar(100)',...]);

[Sir Rufo]

Zitat:

Zitat von Bummi (Beitrag 1174113)

Ein Programm das sich nicht auf dahinterliegende Datenstrukturen verlassen kann ??
Vielleicht solltest Du auf Strukturen wie
[Table_link][TableID][Name][Value] für die ständigen Erweiterungen umstellen, also Daten längs statt Quer verwalten.

:thumb: genau das Bild hatte ich beim Lesen auch im Kopf :)
Das Zauberwort heißt Entity Attribute Value

http://www.informave.org/database-ha...esign_eav.html

[Brinkman]

@bummi: natürlich kann sich das Programm auf die Datenstrukturen verlassen. Sind diese nicht aktuell, werden sie angehoben. Sind sie aktueller als das Programm, dann würde es sich um einen Downgrade handeln, der nicht zulässig ist.

@shmia, Sir Rufo: vielen Dank für die Hinweise. Aber die Frage ging in eine andere Richtung.

Wenn ich dies so recht sehe, dann gib es so eine Universalmigration wohl nicht und ich muss doch auf ssma zurückgreifen ...

Danke trotzdem

[omata]

Zitat:

Zitat von Brinkman (Beitrag 1174148)

Wenn ich dies so recht sehe, dann gib es so eine Universalmigration wohl nicht und ich muss doch auf ssma zurückgreifen ...

Ich habe mich mal dran versucht... klick

[sx2008]

Zitat:

Zitat von Brinkman (Beitrag 1174148)

@shmia, Sir Rufo: vielen Dank für die Hinweise. Aber die Frage ging in eine andere Richtung.

Wenn du 2 Datenbanken hast und alles von A nach B kopieren möchtest, ist es am Einfachsten die Datenbanken zuerst einmal in ihrer Struktur anzugleichen.
Im nächsten Schritt kannst du Tabelle für Tabelle in ihrem Inhalt kopieren.
Eine Funktion zu schreiben, die alle Datensätze einer Tabelle in eine strukturgleiche Tabelle in einer anderen DB kopiert ist nicht so schwer.

Delphi-Quellcode:

{**************************************************************************
 * NAME:    CopyDataSetRecord
 * DESC:    Kopiert alle gleichnamigen Felder aus Src nach Dst.
 *          Dst.State muss in [dsEdit,dsInsert] sein, sonst wird ne
 *          Exception geschmissen.
 *          Es findet keinerlei Prüfung auf Datentypen statt!
 *
 *          Mit TagMask kann das Kopieren von markierten Feldern des Quelldatasets
 *          verhindert werden.
 *************************************************************************}
procedure CopyDataSetRecord(Src,Dst: TDataSet; TagMask:Integer=0);
var
   i: Integer;
   fSrc,fDst: TField;
begin
   for i := 0 to Src.FieldCount-1 do
   begin
      fSrc := Src.Fields[i];
      fDst := Dst.FindField(fSrc.FieldName);

      if Assigned(fDst) and ((fSrc.Tag and TagMask)=0) then
      begin
         fDst.Value := fSrc.Value;
      end;
   end;
end;

procedure DeleteAllRecords(ds: TDataSet);
begin
   ds.DisableControls;
   try
      ds.First;
      while not ds.Eof do
         ds.Delete;
   finally
      ds.EnableControls;
   end;
end;

procedure CopyDataSet(Src,Dst: TDataSet);
begin
   // zuerst alle Datensätze im Ziel löschen
   DeleteAllRecords(Dst);

   Src.First;
   while not Src.Eof do
   begin
      Dst.Append;
      try
         CopyDataSetRecord(Src,Dst);
         Dst.Post;
      except
         Dst.Cancel;
         raise;
      end;
      Src.Next;
   end;
end;

Beim Kopieren der Tabellen gilt es die Reihenfolge zu beachten, da die Tabellen in einer relationalen Datenbank in bestimmten Abhängigkeiten stehen.
Man muss zuerst die Mastertabellen (z.B. Kundenstamm) kopieren und erst danach die Detailtabellen (z.B. Bestelldaten, die sich auf den Kundenstamm beziehen).

[omata]

Zitat:

Zitat von omata (Beitrag 1174261)

Zitat:

Zitat von Brinkman (Beitrag 1174148)

Wenn ich dies so recht sehe, dann gib es so eine Universalmigration wohl nicht und ich muss doch auf ssma zurückgreifen ...

Ich habe mich mal dran versucht... klick

@Brinkman: Schade, das von dir keine Reaktionen mehr kommen.

[sammyskim]

Hallo omata,

habe gerade mal dein Programm ausprobiert. Funktioniert soweit, nur ein kleiner Fehler: Der Connectionstring aus EdConnection wird nicht an die ADOConnection übergeben. Ansonsten feine Sache.