Office: (Office 2003) MS Access als Frontend und MS SQL Server als Backend

Hallo!

Hier im Büro haben wir Access 2003 und MS SQL Server. Meine Abteilung hat eine große Access -DB, die für alle wichtig ist. Aus verschiedenen Gründen soll jetzt die Access DB in der Verknüpfung mit MS SQL Server setzen, also ein Frontend in MS Access(Benutzermaske) und Backend in MS SQL Server(Tabellen mit allen Daten).

Bisher ich habe nur mit MS Access gearbeitet, und von SQL Server habe ich nur wenige Kenntnisse.

Gibt es eine Lösung zu meinem Problem? Was raten Sie mir?


Gruß,

Dan

:)

 

Ich nutze den MSSQL-Server gerne als BE für ein Access-FE.

Bezüglich Umstellung von Access nach MSSQL gab es in der AEK11 einen Vortrag von Bernd Jungbluth. Das Skript "Migration auf SQL Server" ist im AEK-Downloadbereich von www.donkarl.com enthalten.

Eines sollte aber beachtet werden: "nur" die Tabellen auf den MSSQL übertragen und dann wie gewohnt im Access-FE arbeiten, wird vermutlich nicht ausreichen.

 

Vielen Dank für Ihre Information. Zuerst ich versuche mehr von SQL Server zu lernen.
Haben Sie die Verknüpfung zwischen MS Access(FE) and MS SQL Server(BE) gemacht?
Können Sie mir sagen was muss ich beachten? Welchem wichtigen Schritte muss ich machen dass ich die Migration von MS Access nach SQL Server schaffe?

mfg,

Dan

 

Hi,

du kannst hier ruhig Du sagen *wink.gif* Es gibt zwar einen Upsizing Assitenten, aber so wirklich gut finde ich den nicht. Die Verknüpfung erfolgt dann über ODBC. Ich würde mir die Mühe machen und die Tabellen von Hand auf dem Server zu erstellen und dann die Daten rüberzuschaufeln. Dann bin ich mir sicher, dass alles passt. Wenn es zu viele Tabellen sind, solltest du es einfach mit dem Assistenten versuchen und dann die Tabellen miteinander vergleichen, ob auch alles rübergekommen ist.

 

Als Alternative zum Upsizing-Assistenten gibt es noch den SQL Server Migration Assistant.
Wie gut oder schlecht der ist, kann ich aber nicht beurteilen, da ich den noch nie probierte. Wenn ich mir die Funktionalität durchlese gefällt mir das aber um einiges besser als beim Upsizing Assistenten.

 

vor dem gleichen Problem habe ich auch schon gestanden und kapituliert da:

zwar mit dem Assistenten die Tabellen aus dem be nach sqlserver übernommen werden (mit den diversen bekannten einschränkungen)
aber damit ist das fe nicht umgestellt und hier einfach auf ODBC zu gehen bringt nicht wirklich viel, wenn man die diskussionen dazu verfolgt.
was etwas bringen soll ist auf ADO umzustellen und das war zumindest bei mir viel zuviel arbeit, denn da greift kein assistent.

*eek.gif*

 

So allgemein abtun würde ich das nicht. Neben der viel stabileren Datenhaltung und Datensicherung kommt es bei einfachen SQL-Anweisungen auch zu einer Beschleunigung der SQL-Auswertungen, da ODBC durchaus in der Lage ist, die Where-Bedinungen an den DB-Server weiterzureichen.

So "richtig toll" wird ein aktives BE aber erst, wenn man die Fähigkeiten des DBMS nutzt (Sichten, gespeicherte Prozeduren, benutzerdefinierte Funktionen,...), damit dem Server nicht langweilig wird.

Die Nutzung von ADODB ist im Vergleich zur serverseitigen Datenauswertung eine minimale Verbesserung, die ich aber trotzdem gerne einsetze, da ich damit den Server besser bedienen kann. (Das ist aus meiner Sicht eher Programmierkomfort als merkbarer Geschwindigkeitszuwachs für den Anwender.)

 

Es gibt hier
http://cis.cs.tu-berlin.de/Lehre/SS-...c/a11_odbc.pdf
eine ganz gute doku zu ODBC mit Access allgemein.

oder hier:
Blog – berndjungbluth.de

 

Wirklich gute Infos zu Access & ODBC gibt's in einem Dokument von MS, das hier zu finden ist:
http://kbalertz.com/Feedback.aspx?kbNumber=128385
(Exe downloaden und entpacken)
Ist zwar ziemlich veraltet, aber was neueres ähnlich ausführliches gibt es nicht.

Ciao, Sascha

 

Die Übernahme der Tabellen mit dem SQL Server Migration Assistant klappt eigentlich fehlerlos.
Nur bei Abfragen mußt du ins Fehlerprotokoll schauen, welche er übernommen hat und welche eben nicht.

Die Fehlenden erstellst du am einfachsten, wenn du den SQL-String deiner alten Abfrage in eine neue Abfrage des Servers kopierst.
Die dort vorgenommene Syntaxprüfung ist meist sehr hilfreich, da es meist nur wenige, gleiche Fehlerquellen sind:

IIf(....., Last(..., Format(... etc.

Wenn du ADODB verwendest hast du zwar, wie Josef schon sagte, mehr Bedienkomfort, nur deine Berichte funktionieren nicht mehr wie gewohnt.

Das kann man aber über eine flexible Hilfstabelle lösen

 

Ich würde im ersten Schritt die Abfrage als Access-Abfragen laufen lassen und dort wo Bedarf besteht, eine Sicht oder SP erstellen. (Dann kann man diese Umstellung auch gleich nutzen, um die Abfrage zu optimieren.)
Access-Abfragen (ob als gespeicherte Abfrage oder als SQL-Anweisung in der Datenherkunft) werden immer wieder notwendig sein. Vor allem wenn es um Sortierung geht, da z. B. eine Sicht seit SQL 2005 richtigerweise die Daten nicht mehr sortiert liefert, auch wenn ein "Order by"-Teil in der Sicht enthalten ist.

Weiters würde ich z. B. auch nicht versuchen, eine Kreuztabellenabfrage in den Server zu stopfen. Eine KT betrachte ich bereits als "Layout"-Objekt und daher finde ich, dass sie gut ins FE passt.

Zum glück muss man in einer mdb nicht zwangsweise nur DAO oder nur ADODB verwenden und kann beides mischen. *wink.gif*
Für Berichte erstelle ich mir normalerweise ein Sicht oder für komplexere Auswertungen (z. B. bei Einsatz einer SP) gehe ich über eine PT-Abfrage.

 

\@Josef- mal eine Frage zu den Berichten:

Im Moment lasse ich für die Datenherkunft meiner Berichte eine Sicht/SP laufen, erstelle anhand der Feldinhalte/Formate eine lokale Tabelle, die ich wiederum als Datenherkunft verwende.
Die Umwandlung der ADO in DAO-Felder klappt eigentlich prima, die Performance ist auch in Ordnung, NUR :

Das hab ich mir selbst so zusammengereimt, und frage mich natürlich, ob es da einen eleganteren Weg gibt?

 

Ohne Josef zu heißen: Ich würde das ADO-Recordset der Sicht eleganterweise direkt als Datenherkunft des Berichts verwenden (Report.Recordset).
Kommt auf deine Access-Version an.

Ciao, Sascha

 

Soweit war ich auch schon, nur leider steht die Eigenschaft
Report.Recordsource in einer .mdb nicht zur Verfügung.

Ach ja, ich verwende Access XP.

 

Ich erspare mir das mit der Tabelle und verwende die verknüpfte Sicht direkt als Datenherkunft für den Bericht. Der Filter vom Bericht wird ohne Probleme per ODBC an die Sicht weitergeben und im Server normalerweise ein guter Ausführungsplan erstellt.

Meine Variante für komplexere Abfragen:
gespeicherte PT-Abfrage wird mit SQL-Anweisung befüllt. Den Bericht öffne ich dann ohne Filterausdruck, da dieser bereits in der PT enthalten ist.
Damit kann ich dann auch ein gespeicherte Prozedur verwenden.
(Diese Variante ist aber eher ein Sonderfall, meist komme ich mit Sichten für Berichte aus.)