none
Fehler beim Upsizing mdb to sql server

    Frage

  • Hallo

    Da ich möglicherweise das Backend meiner Access-Anwendung (mdb) zukünftig über den SQL-Server laufen lassen möchte, versuche ich derzeit testweise einige Tabellen zu exportieren. Bei den meisten Tabellen geht das ohne Probleme. Aber ein paar Tabellen lassen sich nicht exportieren, weder mit dem Upsizing-Tool noch separat.

    In Access bekomme ich keine Fehler angezeigt nur die Mitteilung, das die Übertragung nicht geklappt hat.

    Wenn ich aber über den SQL-Server die entsprechende Tabelle importiere, bekomme ich schon soweit die Meldung, dass es am Datumsformat liegt, denn ohne Datumsspalten funktioniert es.

    Gibt es etwas, was im vor dem Export zum SQL Server betreffend das Datumsformat oder auch anderer Types in Access beachten muss?

    Ich würde mich über ein paar Tipps bzg. der Types freuen.


    Liebe Grüße, die Luzie!

    Montag, 12. September 2016 07:51

Antworten

  • Hallo,
     
    Luzie wrote:
     
    > [...] SSMA habe ich noch nie benutzt, bzw. bisher nicht gebraucht,  es
    > aber jetzt mal installiert. Allerdings gibt es da ein Problem. Die
    > Access Dateien können nicht eingelesen werden. Mein System ist Windows
    > 10, 64bit und angeblich habe ich nur ein SSMA als 32bit Version
    > installiert und soll jetzt die Komponenten für die 64bit Version
    > herunterladen.
     
    Lass das schoen bleiben.
     
    Beim Setup werden beide (32- und 64-bit) Programmversionen von SSMA
    vollstaendig installiert, benutzen musst du die Variante, die deiner
    Access-Version entspricht. I.d.R. ist das 32-bit, d.h. du startest
    "Microsoft SQL Server Migration Assistant (32-bit)".
     
    Gruss - Peter
     
    --
     
    • Als Antwort markiert Luzie Freitag, 16. September 2016 09:12
    Donnerstag, 15. September 2016 23:30
    Moderator

Alle Antworten

  • Hallo Luzie,

    den Upsizing Wizard habe ich noch nie verwendet, es gibt ab von MS noch das freie Tool SQL Server Migration Assistant for Access (AccessToSQL), vielleicht liefert das bessere Ergebnisse ab. Ich habe das ähnliche Tool für Oracle verwendet und das ging eigentlich ganz gut; nur das es einfach immer Sachen gibt, die man nicht automatisiert konvertieren kann.


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Montag, 12. September 2016 12:37
  • Hallo Luzie,

    uups, den habe ich ewig schon nicht verwendet (und damals eine angepasste Version).

    Sehr wahrscheinlich liegt es an der Formatierung, die beim Erzeugen des SQL verwendet wird. Eine Stellschraube wäre dabei die regionalen Einstellungen  bei der ODBC Verbindung. Die sollte i. a. nicht aktiviert sein, da ansonsten u. a. ein falsches Dezimaltrennzeichen und auch ein anderes Datumsformat verwendet wird.

    Kontrolliere auch die Spracheinstellung für das verwendete SQL Server Konto. Es sollte auf deutsch (german) eingestellt sein; sollte es beim Upsizing nicht funktioneren probiere alternativ us_english, siehe SET LANGUAGE (bzw. Konto-Dialog im SSMS).

    Alternativ verwende den SSMA den Olaf bereits genannt hat.

    Gruß Elmar

    Montag, 12. September 2016 14:27
  • Am 12.09.2016 schrieb Luzie:

    Da ich möglicherweise das Backend meiner Access-Anwendung (mdb) zukünftig über den SQL-Server laufen lassen möchte, versuche ich derzeit testweise einige Tabellen zu exportieren. Bei den meisten Tabellen geht das ohne Probleme. Aber ein paar Tabellen lassen sich nicht exportieren, weder mit dem Upsizing-Tool noch separat.

    Mit den Tools hab ich das noch nie gemacht. Bisher immer die Tabellen
    manuell angelegt.

    Wenn ich aber über den SQL-Server die entsprechende Tabelle importiere, bekomme ich schon soweit die Meldung, dass es am Datumsformat liegt, denn ohne Datumsspalten funktioniert es.

    Gibt es etwas, was im vor dem Export zum SQL Server betreffend das Datumsformat oder auch anderer Types in Access beachten muss?

    Du mußt/sollst dich natürlich vorher mit dem Unterschied in den
    Datentypen beschäftigen. Da gibt es ein paar Stolpersteine,
    Datumsfelder zähle ich auch dazu. ;)

    https://msdn.microsoft.com/de-de/library/office/ff822013.aspx

    Hier ist das Hinweisfeld für dich nicht unwichtig:
    https://msdn.microsoft.com/de-de/library/office/ff193793.aspx

    Servus
    Winfried


    Access-FAQ: http://www.donkarl.com/AccessFAQ.htm Access-Stammtisch: http://www.access-muenchen.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/
    vbeTwister: http://www.vbetwister.com/

    Montag, 12. September 2016 16:37
  • Hallo

    also den Upsizing-Assistenten muss ich nicht verwenden, die Tabellen sind noch überschaubar und auch händisch zu konvertieren. Das ich die Types anschließend kontrollieren muss, ist klar. 

    Was eigentlich komisch ist, dass einige Tabellen ohne Probleme konvertiert werden (auch mit Datum)  - Umwandlung im SQL-Server nach Datetime(7) und andere Tabellen mit gleichen Datumseinstellungen wo ich nicht umwandeln kann, weder manuell noch über Upsizing. Aber was geht ist von Access nach Excel und von Excel nach SQL Server und dann die Types wieder einstellen, so wie ich das sehe auch ohne Datenverlust.

    Danke für die Links, die schaue ich mir an. Language beim SQL Server ist auf German eingestellt.

    Also ich bin ja jetzt Beginner was Access in Verbindung mit SQL Server angeht und habe noch eine Frage: ich arbeite gerne mit gespeicherten Prozeduren und kleinen Funktionen im SQL Server. Sowas kann ich für Access nicht verwenden oder doch?


    Liebe Grüße, die Luzie!

    Dienstag, 13. September 2016 09:53
  • Hallo Luzie,

    In MS Access kannst Du Pass-Through-Abfragen anlegen, die dann 1:1 gegen die externe Datenquelle ausgeführt werden, auf die Art kannst u.a. Stored Procedures ausführen oder T-SQL Funktionen von Access aus verwenden; siehe Accessing External Data with MS Access


    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Dienstag, 13. September 2016 10:49
  • Hallo

    danke für die Info.

    Da muss ich mich mit beschäftigen. Wie ich das verstanden habe, kann ich auch auf views und Tabellen zugreifen, ohne sie vorher mit Access verknüpft zu haben. Das wäre klasse. Oder ist es performancetechnisch besser, wenn ich die Tabellen direkt in Access verknüpfe? Oder denke ich zu kompliziert?


    Liebe Grüße, die Luzie!

    Dienstag, 13. September 2016 15:45
  • Am 13.09.2016 schrieb Luzie:

    Da muss ich mich mit beschäftigen. Wie ich das verstanden habe, kann ich auch auf views und Tabellen zugreifen, ohne sie vorher mit Access verknüpft zu haben. Das wäre klasse. Oder ist es performancetechnisch besser, wenn ich die Tabellen direkt in Access verknüpfe? Oder denke ich zu kompliziert?

    Das kann man machen wie man möchte, ich vermeide es mittlerweile so
    weit wie möglich. Auf der AEK 17 hat Bernd einen Vortrag dazu
    gehalten: http://donkarl.com/aek/Archiv/AEK17.htm Im Downloadbereich
    kannst Du dir die Unterlagen dazu downloaden:
    http://donkarl.com/Downloads/AEK/ Am besten mal die SQL Scripte und
    das Beispiel FE anschauen, dabei wird vieles klarer.

    Ohne eingebundene Tabellen und Views bist Du IMO viel flexibler. Und
    ja, so eine Umstellung macht man nicht einfach so, Einarbeitung und
    ein Gefühl dafür bekommen dauert einfach ein bisschen. ;)

    Servus
    Winfried


    Access-FAQ: http://www.donkarl.com/AccessFAQ.htm Access-Stammtisch: http://www.access-muenchen.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/
    vbeTwister: http://www.vbetwister.com/

    Dienstag, 13. September 2016 16:44
  • Hallo,
     
    Den Hinweis zu SSMA hast du schon mehrfach bekommen. Der Vorteil des Tools
    ist u.a. auch, dass er sowohl Schema als auch Daten prueft und potentielle
    Probleme in einem Report auflistet.
     
    Ein typisches Upsizing-Problem bei Datumsfeldern sind Falscheingaben in
    Access, die zu Werten fuehren, die vor dem 01.01.1753 liegen, was das
    niedrigste erlaubte Datum am SQL Server ist. Beispiel: wenn statt
    14.09.2016 => 14.09.201 eingegeben wurde, ist das Datum in Access immer
    noch gueltig, fuehrt aber bei der Migration zu Fehlern.
     
    Kann das sein?
     
    Gruss - Peter
     
    --
     
    Mittwoch, 14. September 2016 11:07
    Moderator
  • Hallo

    erstmal danke für die Antowrten.

    Ich bin jetzt mal bei einer Tabelle die Datumswerte durchflogen, habe aber keine falsche Eingabe entdeckt.

    Testdb

    Ich habe einen Auszug der fehlerhaften Tabelle mal hochgeladen. Vielleicht könnte jemand mal reinschauen.

    Wenn ich Tabelle vom SQL Server aus importiere, werden nur die ersten 21.000 Datensätze importiert, der Rest wird ignoriert.

    Dies ist der Bereicht
    - Es wird kopiert in '[dbo].[TaAnlAdr]' (Fehler)
    Meldungen
    Fehler 0xc0202009: 1-Datenflusstask: SSIS-Fehlercode 'DTS_E_OLEDBERROR'. OLE DB-Fehler. Fehlercode: 0x80004005.
    Ein OLE DB-Datensatz ist verfügbar. Quelle: 'Microsoft SQL Server Native Client 11.0' HRESULT: 0x80004005 Beschreibung: 'Invalid date format'.
     (SQL Server-Import/Export-Assistent)
     
    Fehler 0xc020901c: 1-Datenflusstask: Fehler bei 'Ziel - TaAnlAdr.Eingaben[Destination Input].Spalten[Anreise]' für 'Ziel - TaAnlAdr.Eingaben[Destination Input]'. Folgender Spaltenstatus wurde zurückgegeben: 'Fehler bei der Konvertierung, weil der Datenwert zu einem Überlauf beim angegebenen Typ führte.'.
     (SQL Server-Import/Export-Assistent)
     
    Fehler 0xc0209029: 1-Datenflusstask: SSIS-Fehlercode 'DTS_E_INDUCEDTRANSFORMFAILUREONERROR'. Fehler bei 'Ziel - TaAnlAdr.Eingaben[Destination Input]' aufgrund des Fehlercodes 0xC020907A. Die Fehlerzeilendisposition in 'Ziel - TaAnlAdr.Eingaben[Destination Input]' gibt an, dass der Vorgang bei einem Fehler nicht ausgeführt werden kann. Es wurde ein Fehler im angegebenen Objekt der angegebenen Komponente festgestellt. Möglicherweise wurden bereits Fehlermeldungen veröffentlicht, die weitere Fehlerinformationen beinhalten.
     (SQL Server-Import/Export-Assistent)
     
    Fehler 0xc0047022: 1-Datenflusstask: SSIS-Fehlercode 'DTS_E_PROCESSINPUTFAILED'. Fehler bei der ProcessInput-Methode in der Komponente 'Ziel - TaAnlAdr' (85) mit dem Fehlercode 0xC0209029 beim Verarbeiten der Eingabe 'Destination Input' (98). Die identifizierte Komponente hat einen Fehler von der ProcessInput-Methode zurückgegeben. Der Fehler ist komponentenspezifisch. Es handelt sich jedoch um einen schwerwiegenden Fehler, sodass die Ausführung des Datenflusstasks unterbrochen wird. Möglicherweise wurden bereits Fehlermeldungen veröffentlicht, die weitere Fehlerinformationen beinhalten.
     (SQL Server-Import/Export-Assistent)
     
    Fehler 0xc02020c4: 1-Datenflusstask: Fehler beim Hinzufügen einer Zeile zum Datenflusstask-Puffer (Fehlercode: 0xC0047020).
     (SQL Server-Import/Export-Assistent)
     
    Fehler 0xc0047038: 1-Datenflusstask: SSIS-Fehlercode 'DTS_E_PRIMEOUTPUTFAILED'. Die PrimeOutput-Methode in 'Quelle - TaAnlAdr' hat den Fehlercode 0xC02020C4 zurückgegeben. Die Komponente gab einen Fehlercode zurück, als das Pipelinemodul 'PrimeOutput()' aufgerufen hat. Die Bedeutung des Fehlercodes wird von der Komponente definiert. Der Fehler ist jedoch schwerwiegend, und die Ausführung der Pipeline wurde beendet. Möglicherweise wurden bereits Fehlermeldungen veröffentlicht, die weitere Fehlerinformationen beinhalten.
     (SQL Server-Import/Export-Assistent)

    Liebe Grüße, die Luzie!

    Donnerstag, 15. September 2016 08:00
  • Hallo,
     
    Luzie wrote:
     
    > Testdb
    >
    > Ich habe einen Auszug der fehlerhaften Tabelle mal hochgeladen.
    > Vielleicht könnte jemand mal reinschauen.
     
    Ich hab die Tabelle testweise bei mir per SSMA nach SQL 2014 migriert, ohne
    Probleme. Der Bericht hat folgende Warnungen ausgegeben:
     
    - The bit column 'stAkzeptiert' has no default value. To avoid problems
    with null values in Access applications, the default value '0' was added to
    target column.
    - Gleiche Meldung fuer Spalte 'saq'.
     
    Mit Datumsfeldern gab es keine Probleme.
     
    Gruss - Peter
     
    --
     
    Donnerstag, 15. September 2016 10:39
    Moderator
  • Hallo Peter,

    danke fürs Testen.

    Ich importiere die Daten immer über die normale Import-Funktion des SQL Servers. SSMA habe ich noch nie benutzt, bzw. bisher nicht gebraucht,  es aber jetzt mal installiert. Allerdings gibt es da ein Problem. Die Access Dateien können nicht eingelesen werden. Mein System ist Windows 10, 64bit und angeblich habe ich nur ein SSMA als 32bit Version installiert und soll jetzt die Komponenten für die 64bit Version herunterladen.

    Jetzt habe ich 2 unterschiedliche Versionen installiert und deinstalliert. Ein Hinweis auf die Version konnte ich beim Download nicht finden.

         An error occurred while loading database information.
    Access Object Collector error: Database
         Die COM-Klassenfactory für die Komponente mit CLSID {CD7791B9-43FD-42C5-AE42-8DD2811F0419} konnte aufgrund des folgenden Fehlers nicht abgerufen werden: 80040154 Klasse nicht registriert (Ausnahme von HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)). This error may be a result of running SSMA as 64-bit application while having only 32-bit connectivity components installed or vice versa. You can run 32-bit SSMA application if you have 32-bit connectivity components or 64-bit SSMA application if you have 64-bit connectivity components, shortcut to both 32-bit and 64-bit SSMA can be found under the Programs menu. You can also consider updating your connectivity components from http://go.microsoft.com/fwlink/?LinkId=197502.
         An error occurred while loading database content.

    Ich bin echt mit meinem Latein am Ende.


    Liebe Grüße, die Luzie!

    Donnerstag, 15. September 2016 16:34
  • Hallo,
     
    Luzie wrote:
     
    > [...] SSMA habe ich noch nie benutzt, bzw. bisher nicht gebraucht,  es
    > aber jetzt mal installiert. Allerdings gibt es da ein Problem. Die
    > Access Dateien können nicht eingelesen werden. Mein System ist Windows
    > 10, 64bit und angeblich habe ich nur ein SSMA als 32bit Version
    > installiert und soll jetzt die Komponenten für die 64bit Version
    > herunterladen.
     
    Lass das schoen bleiben.
     
    Beim Setup werden beide (32- und 64-bit) Programmversionen von SSMA
    vollstaendig installiert, benutzen musst du die Variante, die deiner
    Access-Version entspricht. I.d.R. ist das 32-bit, d.h. du startest
    "Microsoft SQL Server Migration Assistant (32-bit)".
     
    Gruss - Peter
     
    --
     
    • Als Antwort markiert Luzie Freitag, 16. September 2016 09:12
    Donnerstag, 15. September 2016 23:30
    Moderator
  • Hallo Peter,

    es gibt tatsächlich 2 Versionen. Ich habe es jetzt mit der vorgeschlagenen 32-bit-Version probiert und Access wird auch gefunden.

    Bei der Tabelle habe ich nochmals alle Standardwert nachgearbeitet und Null durch 0 ersetzt, wo es hinkommt. Jetzt lässt sie sich prima mit dem SSMA migrieren.

    Ich bin so froh, wieder eine Baustelle weniger. :)

    Vielen Dank nochmal an alle, die mir hier geholfen haben.



    Liebe Grüße, die Luzie!

    Freitag, 16. September 2016 09:12
  • Hallo,

    ich habe das gleiche Problem, dass ich meine mdb Datenbank nicht in im Microsoft SQL Server Migration Assistant geladen bekomme.

    Ich habe ebenfalls eine office 2016 32 bit version

    Es nur eine SSMAA Version bei mir installiert und gibt keine 32 Bit version. 

    Habe diverse SSMAA Versionen (immer die komplettversion) probiert. 

    Ich nutze Windows 8 32 bit. 

    Kann es daran liegen?

    Ich finde und finde die Lösung nicht. 

    Für Rat sehr dankbar

    Anton

    Samstag, 1. Juli 2017 09:51
  • Hallo,
     
    AntonSteglitz wrote:
     
    > ich habe das gleiche Problem, dass ich meine mdb Datenbank nicht in im Microsoft SQL Server Migration
    > Assistant geladen bekomme.
    >
    > Ich habe ebenfalls eine office 2016 32 bit version
    >
    > Es nur eine SSMAA Version bei mir installiert und gibt keine 32 Bit version.
    >
    > Habe diverse SSMAA Versionen (immer die komplettversion) probiert.
    >
    > Ich nutze Windows 8 32 bit.
    >
    > Kann es daran liegen?
     
    Nein.
     
    Wenn du SSMA erst kuerzlich runtergeladen hast, könntest du Version 7.4
    bekommen haben und auf der Seite gibt es eine Bemerkung, dass ab v7.4 die
    32-bit-Version nicht mehr unterstützt wird :-(
     
    Du müsstest also eine Version vor 7.4 runterladen/installieren, dann
    klappts auch mit 32-bit.
     
    Es kann übrigens sein, dass du das 32-bit-Programm nicht im Start-Menue
    findest. Es ist aber installiert, du müsstest dann im Programmordner
    suchen.
     
    Gruss - Peter
     
    --
     
    Mittwoch, 5. Juli 2017 08:26
    Moderator
  • Hallo Peter,

    Dank dir für deine Antwort.

    Ich hatte ältere Versionen benutzt. Die Lösung ist: Da mein OS 32 Bit ist, wurde auch nur die ssma 32 bit installiert.

    Habe nun zusätzlich Access Runtime 2013 installiert und jetzt funktioniert es...

    Habe mich an dieser Anleitung orientiert, die eigentlich will, dass man ssma 64 bit benutzt

    HIlft aber auch spiegelbildlich wenn man ssma 32 bit benutzen will.

    https://blogs.msdn.microsoft.com/datamigration/2016/12/16/access-connectivity-components-for-ssma/

    Danke

    Der erste Schritt zur MIgration ist geschafft.


    Freitag, 7. Juli 2017 08:58