SQL-Server - Version?

Hallo,

Die Möglichkeit der Bearbeitung von Objekten in ADP gab es immer nur für die zum Zeitpunkt des Office-Release bekannten SQL Server Versionen, im Falle von Office 2010 also bis SQL Server 2008 R2, denn 2012 kam erst später auf den Markt. Das ist normal und
war schon immer so. Neu und bedauerlich ist, dass mit der Einstellung des ADP-Supports in Office 2013 ADP aus 2010 die letzten sein werden, mit denen man bis SQL Server 2008 R2 Objekte bearbeiten kann.

ADP-Anwendungen funktionieren hingegen auch mit neueren SQL Server Versionen. Lediglich die Möglichkeit der Änderung von Objekten ist nicht mehr gegeben. Dazu hat man das SQL Server Management Studio (SSMS).

Gruss - Peter

Hallo,

Das ist keine "gangbare", sondern die
korrekte Lösung.

SSMA erlaubt, das Mapping für jeden einzelnen Feldtyp individuell pro Projekt zu bestimmen, auch als Standard für alle weiteren Migrationsprojekte. Insofern wäre es für dich wahrscheinlich weniger Arbeit gewesen, die Migration mit dem korrekten Mapping zu
wiederholen.

Für Datumsfelder gilt:

• Type DateTime in Access entspricht weitgehend dem Typ DateTime (ohne 2) auf SQL Server.
• Das niedrigst mögliche Datum in Access ist der 01.01.100, das auf SQL Server für DateTime: 01.01.1753. Wichtig ist diese Erkenntnis bei Eingabefehlern. Wenn statt Jahr 2020 z.B. 202 eingegeben wurde, führt das bei der Migration zu Fehlern.
• Um DateTime2 in Access einbinden zu können, müssen neuere Treiber eingesetzt werden. Der Treiber "SQL Server" stammt aus Zeiten von SQL Server 2000, als es DateTime2 noch nicht gab, und beim Verknüpfen in Access werden alle unbekannten Datentypen als Text
  eingebunden. Mindestens seit "SQL Server Native Client 10.0" ist DateTime2 bekannt. Aktuellster Treiber ist
  
  ODBC Driver 17 for SQL Server, der alle Versionen von SQL Server seit 2008 bis einschl. SQL Azure unterstützt.
• Der einzige Vorteil des Treibers "SQL Server" gegenüber den neueren ist, dass er im Windows-Setup enthalten ist, während die neueren selbst installiert werden müssen.

HTH - Peter

Hallo Joern4,

Die Aussage bez. Access und Decimals, die nur als Text eingebunden werden können, ist so nicht korrekt.

Decimal (SQL Server) kann sehr wohl als Decimal (Access) eingebunden werden, vorausgesetzt, die Dimensionierung liegt bei max. 28 Stellen, wobei Scale oder Precision egal sind, d. h. Decimal(28,0) bis Decimal(28,28)
werden in Access als Decimal eingebunden, alles darüber wird zu Short Text.

Getestet mit Access 2016 32-bit und SQL Server 2016 und den Providern:

- SQL Server

- SQL Server Native Client 11.0

- ODBC Driver 13 for SQL Server

Gruss - Peter

Hallo Gijs,

das hatte ich schon versucht. Diese Datei für den SQL-Server kann ich aber mit Access nicht öffnen. Ich glaube, da gibt es auch eine accdb-version von.

LG

Ingo

Hallo André



ist nicht meine. Nein, die Datenbank ist nicht geschützt.

Bin ein Stückchen weiter.

In der Tabelle orgTable steht im Feld SharedServer der Rechnername drin. Auch wenn die Datenbank nur lokal benutzt wird. Da der Kunde seinen neuen Rechner mit einem neuen Namen versehen hat, funktioniert ein Backup/Restore nicht.

Ich habe leider dir Original mdf/ldf Dateien nicht koepiert, sondern direkt attached. Leider mit einer zu hohen Version des SQL Servers (2008 R2).

Dort habe ich diesen Tabelleneintrag korrigiert.

Beim Import läuft er jetzt ein Stückechen weiter, aber meckert dann die zu hohe SQL Version an...

Habe jetzt unter einer virtuellen Umgebung den SQL Server 2008 installiert, leider muss ich jetzt auf das Original (ldf/mdf) warten, weil durch das attchen im SQL Server 2008 R2 die Datei nicht mehr mit dem SQL Server 2008 verbunden werden kann.

Ein Export/Import bringt leider auch nichts, weil alle Views dabei zu Tabellen umgewandelt werden und über 9 GB groß werden. Zuviel Handarbeit notwendig Da warte ich auf den Kunden (in 2 Tagen)

was mich frustiert, dass die Fehlermeldung absolut gar nichts bringen.

Werde, wenns funktioniert , ein Update (oder vielleicht ein Blog schreiben)



Hans