Kategorie: "SQLServer"

ADO - Abkündigung der Abkündigung <g> - die unendliche Geschichte

Hi,

Announcing the new release of OLE DB Driver for SQL Server 

dieser Microsoft Blogeintrag (hier ein großes Danke an Bernd Jungbluth für die Info) besagt, dass MS ADO nun doch weiterentwickelt wird.

Ich habe von Anderen bisher noch keine Rückmeldung erhalten, aber es sieht so aus, dass man "mit gutem Gewissen" mit ADO (Weiter-)Entwickeln kann, und man bei MS Access < - > SQL Server auf ADO setzen könne.  Ich habe aufgrund der "Depreciation von ADO" daher bisher ausschliesslich DAO verwendet ... 

Da sogar der Blog-Eintrag der "Depreciation selbst" (von 2011) hier mit einer Headline versehen wurde, scheint MS das wohl ernst zu meinen.

Was meint Ihr dazu ?

Nachtrag:

Eine Bestätigung / Reaktion zu diesem Artikel kam von der internationalen Access-User-Group (Juan e Soto), der den positiven Einfluss auf Access bestätigte

Access Expert Artikel

mfg

Klaus Oberdalhoff

SQL Server Migration Assistant für Access - 32 / 64 Bit Problematik

see below the english translation of the article

 

Aus aktuellem Anlass hier einige Infos zum "SQL Server Migration Assistant für Access" (SSMA)

Microsoft hat in seiner unendlichen und  unermesslichen Weisheit beschlossen, den SSMA für Access ab der Version 7.4 nur noch als 64 Bit Version anzubieten.

Meine persönliche Meinung zu diesem überaus sinnigen Entschluss ist weitgehend der Selbstzensur zum Opfer gefallen ...

 Verschlimmert wird dieser Entschluss durch folgende zwei Tatsachen:

  1. Die letzte 32-bit Version des SSMA für Access 7.3 steht bei Microsoft nicht mehr zum Download bereit.
  2. Es scheint überaus schwierig zu sein, einen vernünftigen 64-Treiber zu finden, der - bei einer installierten 32-bit Version von Office - sich vernünfig installieren lässt und mit 32-bit Versionen von Access zusammenarbeirtet.

 Die von mir hier vorgeschlagene Lösung ist:

Die in meinem Onedrive hier im Unterverzeichnis SSMA 1.73 verwendete Version 1.73 zu installieren. Diese ist die letzte Version, die auch als 32-bit Variante ausgeliefert wurde.

Er arbeitet problemlos mit SQL Server 2016 zusammen. Für SQL Server 2017 muss man wohl die neuere - 64-bit only - Variante verwenden und versuchen, diese zum Laufen zu bekommen.

NEU: Eigene Tests haben mir gezeigt, dass die Version 7.3 auch wunderbar mit der neuen SQL Server 2017 Version zurande kommt. (Man muss nur beim ersten Start "SQL Server vNext (Windows) -preview" angeben)

Dieser SSMA 7.6 64bit Info Artikel beschreibt aus MS Sicht, was zu tun ist, um mit dem 64-bit Tool zu arbeiten.

 

Tipps zur Arbeit mit SSMS

Für Access empfiehlt es sich dringend, die Datentypen anzupassen.

Der SQL Server Datetime2 Datentyp wird von manchen Treibern nicht korrekt als Datetime erkannt und sollte daher nicht verwendet werden. Daher ist besonders die Änderung der Zuordnung des Datentyps Date/Time (Access) in den bewährten Datetime wichtig.

Ebenso ist es wichtig, bei der Konvertierung einzustellen, dass für jede Tabelle ein Feld Timestamp erstellt wird.

 

Vor der Konvertierung sich unbedingt die Access Indizes ansehen, die Doppelten (die Access oft automatisch anlegt) löschen sowie sich alle Indizes zu notieren, die

Unique aber mit mehrfach NULL erlaubt sind (Unique Index with NULL), und diese vor der Konvertierung zu löschen.

 

Im SQL Server (ab 2008R2) können Unique Index with NULL einfach wie folgt neu erzeugt werden:

 

/****** Object:  Index [idx_Kunde_Matchcode_notnull]    Script Date: 09.04.2017 22:11:26 ******/

CREATE UNIQUE NONCLUSTERED INDEX [idx_Artikel_Matchcode_notnull] ON [dbo].[tblStamm_Artikel]

(

                [a_Matchcode] ASC

)

WHERE [a_Matchcode] IS NOT NULL;

GO

  

SQL Server Data Tools (SSDT)

 Neben der reinen Konvertierfunktion bietet dieses Tool die Möglichkeit, ein SSDT Projekt zu erzeugen. Ebenso kann auch ein SQL-Script erzeugt werden.

 Info zu SSDT:

 https://msdn.microsoft.com/de-de/library/hh272686(v=vs.103).aspx

https://docs.microsoft.com/de-de/sql/ssdt/download-sql-server-data-tools-ssdt

Wichtig: Gerade auch mit dem SQL Server 2017 ausprobiert: Man kann auch WUNDERBAR SSDT-Scripte oder SQL Scripte von irgendwelchen bereits bestehenden SQL Server Datenbanken (die NICHT mit dem SSMA konvertiert wurden) erzeugen. D.h. für die Arbeit mit SSDT ist der SSMA geradezu eine "Wunderwaffe" <g>

 SSDT für Visual Studio 2015 und SSDT für Visual Studio 2017 verwenden beide DacFx 17.2: Data-Tier Application Framework (DacFx) 17.2 herunterladen

Für den Fall, dass die Daten für VS2015 bei MS nicht mehr verfügbar sein sollten, sind sie im ssma Directory unter sonstiges enthalten.

 Nähere Infos siehe Readme.pdf im Onedrive-Ordner

 

 

------------------ english version -------------------------

 

SQL Server Migration Assistant for Access - 32/64-bit problematic

Due to recent events here some info on "SQL Server Migration Assistant for Access" (SSMA)

Microsoft has decided in its infinite and immeasurable wisdom to offer the SSMA for Access as of version 7.4 only as a 64 bit version.

My personal opinion on this "very intelligent and thoughtful" decision has largely fallen victim to self-censorship...

  This decision is exacerbated by the following two facts:

  1. The last 32-bit version of the SSMA for Access 7.3 is no longer available for download at Microsoft.
  2. It seems to be extremely difficult to find a reasonable 64 driver that can install and work reasonably well with an installed 32-bit version of Office and with 32-bit versions of Access

The solution I have proposed here is:

Use the SSMA version 1.73, which i put   in my Onedrive   in  subdirectory SSMA 1.73. This is/was the last version, which was also delivered as a 32-bit version.

It works seamlessly with SQL Server 2016.   For SQL Server 2017 you probably need the newer - 64-bit only - use variant and try to get this to work.

NEW: My tests have shown me that version 7.3 is also wonderful working with the new version of SQL Server 2017. (You just have to specify when you first start "SQL Server vNext (Windows) -preview")

This   SSMA 7.6 64bit Info Article   describes from MS's point of view what to do to work with the 64-bit tool.

 

Tips on working with SSMS

For Access, it is strongly recommended to customize the data types.

The SQL Server datetime2 data type is not correctly recognized as a datetime by some drivers and therefore should not be used. Therefore, especially the change of assignment of data type Date / Time (Access) in the proven ‘old’ datetime is important.

Similarly, it is important to set the conversion to create a timestamp field for each table.

 Before conversion, be sure to view the access indices and record all indexes that are Unique with multiple nulls allowed (unique index with NULL), and delete them before conversion. SSMS does not convert them correctly.

 In SQL Server (2008R2 or later versions) Unique index with zero can easily be re-created as (filtered index) follows:

 

/ ****** Object:   Index [idx_Kunde_Matchcode_notnull]     Script Date: 09.04.2017 22:11:26 ****** /

CREATE UNIQUE NONCLUSTERED INDEX [idx_article_Matchcode_notnull] ON [dbo]. [TblStamm_Article]

(

                [A_Matchcode] ASC

)

WHERE [a_Matchcode] IS NOT NULL;

GO

  

SQL Server Data Tools (SSDT)

Besides pure conversion function, this tool provides the ability to generate an SSDT project. An SQL script can also be generated.

  About SSDT:

  https://msdn.microsoft.com/en-us/library/hh272686(v=vs.103).aspx

https://docs.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt

Tried (incl. SQL Server 2017) - Important: You also can create SSDT- scripts or SQL scripts (of any existing SQL Server databases   NOT   converted with the SSMA). This means that the SSMA is a "miracle weapon" <g> for working with SSDT

I personally always create TWO versions of the database, one WITH timestamp-field at the end of each table, and one WITHOUT. The reason: If ssdta is installed, VS offers on right-click of the database a script "create all CRUD-Stored procedures" for the database. I use the script WITHOUT the timestamp (and automatically create the opposite part with vba / dao on the Access side) then i delete the created database without timestamp ...

Both use DacFx 17.2 SSDT for Visual Studio 2015 and SSDT for Visual Studio 2017: Data-Tier Application Framework (DacFx) 2.17.

Reporting Services Datenbank von einem anderen Rechner als Eigene übernehmen

Hi,

da ich so meine Probleme mit der korrekten Übertragung der ReportingServices hatte, hier mein Leitfaden dazu:

Wenn man die ReportingServices Datenbanken "ReportServer" und "ReportServerTempDB" von einem anderen Rechner auf seinen übertragen möchte, so ist folgendes zu beachten:

Vor dem Einspielen der "neuen" ReportingServices &amp; Temp Datenbank, sicherheitshalber die eigenen "alten" ReportingServices &amp; Temp als Backup sichern (Also diejenigen, die man überschreiben möchte)

WICHTIG:

Bitte machen Sie davor mittels SSRS Configuration Manager / Encryption Keys ein Backup der Keys (1 kb groß) “Backup the key to a password protected ….“ ... und speichern diese Datei zusammen mit dem zur Erstellung des Encryption Backups verwendeten Passwort. Ohne diesen Schritt können die alten ReportingServices nach dem zurückspielen nicht mehr verwendet werden.

Die "neuen" ReportingServices müssen zusätzlich zu den ReportingServices &amp; Temp Datenbanken den Encryption Key (Eine 1kb große "snk" Datei) enthalten, sowie die Info über das Passwort, das beim Extrahieren verwendet wurde.

Um die "neuen" ReportingServices verwenden zu können:

Schritt 1:
Wie beschrieben Datenbank Backup (Alt) und Encryption Key und Passwort Sicherung

Schritt 2:
Stoppen SQL und Reporting Services

Schritt 3:
Löschen der "alten" ReportingServices &amp; Temp Datenbanken aus dem SQL Server

Schritt 4:
Kopieren "neuen" ReportingServices &amp; Temp Datenbanken in dem SQL Server

Schritt 5:
Starten SQL und Reporting Services

Schritt 6:
Starten des SSRS Configuration Manager / Encryption Keys
Importieren des "neuen" Encryption Keys mittels des gleichen Passwortes, das bei seinem Export verwendet wurde.

NEU WICHTIG: Schritt 6 a

Sofern die Datenbanken auf einer Neueren Version "eingespielt" werden, ist es wichtig, die Datenbank auf die höchste verfügbare Version zu stellen.

Wenn die "alte" Version sqö 2008R2 war und die neuere 2016, so muss unter EIgenschaften Optionen die Datenbank auf 130 (2016) gestellt werden.

 

Schritt 7:
Um die Reporting Services direkt vom IE aus starten und verwalten zu können:

Reporting Services Config Manager starten und sich verbinden
Verwendeten Link aus Reporting Services Config Manager / "Report Manager URL" eruieren.

Link direkt starten und sich die gezeigten Unterverzeichnisse merken

Config Manager schliessen

WICHTIG: Internet Explorer als ADMINISTRATOR starten

Eruierten Link aufrufen

Dort rechts oben unter

Siteeinstellungen

Sicherheit

Mein eigenes (Windows) Konto als Administrator hinzufügen

Danach Stamm
Ordnereinstellungen
Sicherheit

Mein eigenes (Windows) Konto als Inhalts Manager (Content Manager) hinzufügen

IE Schliessen, normal starten, testen.

Schritt 7a:
ACHTUNG: Bei bestehenden Reporting Services:

Sofern man im 'normalen' IE keine / nicht alle Reportverzeichnisse sieht, die man sieht, wenn man den Link via Conf Manager startet, ist man in den Unterverzeichnissen nicht als Content Manager hinzugefügt worden.

In diesem Falle Site via Reporting Services Content Manager aufrufen und im jeweiligen Unterverzeichnis unter Security sein eigenes Konto als Inhaltsmanager (Content Manager) hinzufügen.

Alles schliessen

IE normal starten, jetzt sollte man alle Unterverzeichnisse sehen

Schritt 8:
Datenquellen ändern

In allen Unterverzeichnissen alle Datenquellen ändern, so dass Sie auf den richtigen Server zeigen, testen.

Danach sollte man die "neuen" ReportingServices "ganz normal" verwenden können, sofern man Zugriff auf alle benötigten Datenquellen hat.

mfg
Klaus Oberdalhoff

Access und SQL Server - Frische Downloads

Hi, auf meiner Homepage habe ich eine Sammlung praktischer Routinen, Formulare und Tabellen zum kostenfreien Download bereitgestellt. OK, einige wenige Module werden die einen oder anderen aus der KnowHow kennen, aber das Meiste ist neu oder verbessert. Ich nutze diese Datenbank selbst als "Master"-Datenbank, wenn ich neue Programme entwickle. Es existieren zwei Versionen: a) SQL Server (ab 2008R2) als Backend und Access (ab 2003) als Frontend b) Pur Access Zusätzlich habe ich ein Excerpt daraus, den 'Code-Lurker' bereitgestellt. Das Programm 'Code-Lurker' basiert auf der inoffiziellen Funktion 'Application.SaveAsText' die aus allen Objekten der Datenbank - ausser den Tabellen - (hier verwendet: Formular, Modul, Report) eine Textdatei erstellt. Nach Erzeugung dieser Textdateien werden diese aufbereitet in eine Tabelle eingelesen und können so einfach durchsucht werden. Viel Spass beim Ausprobieren Hier der Link: http://sql-insider.de/nuetzliche-masken-und-programme-/index.php mfg Klaus

Migrationshilfe von Access nach SQL Server: Beschreibungen der Textfelder aus Tabellen übernehmen

Hi, da ich zwar im SQL Server weiss, wie man Text-Beschreibungen (Extended Properties) einpflegt, aber keinen Automatismus gefunden habe, wie man den sonst brauchbaren MS Migration Assistant for SQL Server dazu überreden kann, das zu tun, habe ich mir eine kleine Access-Datenbank gebastelt, die automatisch eine SQL-Prozedur für alle gefundenen Beschreibungen von Tabellenfeldern erstellt. Idee: Einfach gewünschte Tabellen in diese Hilfs-Datenbank einbinden und Script laufen lassen, dann wird ein Script erzeugt. USE Yourdatabase anpassen ... Beim Aufruf kann man entscheiden, ob man evtl bestehende Beschreibungen im SQL Server überschreiben möchte, oder nicht. (Bei Wunsch nach Überschreiben wird hintereinander eine SP_CreateExtendedProperty und danach eine SP_UpdateExtendedProperty erzeugt) Ebenso kann man entscheiden, ob man eingebundene Tabellen aus- oder einschließen möchte. Achtung: Keine Benutzeroberfläche, Einfach Modul öffnen ... Vielleicht findet es der Eine oder Andere ganz hilfreich ... extended_Property_uebernehmen.zip mfg Klaus
1 3 4