Fehler beim Upsizing mdb to sql server

Question

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!

Answer 1

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]

Answer 2

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

Answer 3

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/

Answer 4

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!

Answer 5

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]

Answer 6

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!

Answer 7

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/

Answer 8

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

 

--

Mitglied im http://www.dbdev.org

FAQ: http://www.donkarl.com

 

Answer 9

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!

Answer 10

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

 

--

Mitglied im http://www.dbdev.org

FAQ: http://www.donkarl.com

 

Answer 11

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!

Answer 12

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

 

--

Mitglied im http://www.dbdev.org

FAQ: http://www.donkarl.com

 

Answer 13

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!

Answer 14

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

Answer 15

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

 

--

Mitglied im http://www.dbdev.org

FAQ: http://www.donkarl.com

 

Answer 16

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.