Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
Grundsätzliche Tipps zu Umstellung DAO -> ADO
Gehe zu Seite 1, 2  Weiter
zurück: Neuer Datensatz mit Button anlegen weiter: mit opentextfile 2 oder mehr datein gleíchzeitig einlesen Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Antwort Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
Speed Pete
Im Profil kannst Du frei den Rang ändern


Verfasst am:
25. Sep 2009, 10:54
Rufname:

Grundsätzliche Tipps zu Umstellung DAO -> ADO - Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Eine Datenbank von mir wurde als reine Access DB programmiert - dabei habe ich DAO verwendet. Nun soll die Datenbank auf MS SQL Server umgestellt werden, was für mich absolutes Neuland ist.
Ich habe schon eifrig gelesen und es ist nun klar: dazu muss ich meinen Programmcode auf ADO umstellen. und nun frage ich mich, wie ich das am klügsten anstelle.

Ist es richtig, dass ich einfach bei den Verweisen im VBA Editor DAO weg klicke und dafür DAO aktiviere? Und wenn dann mein Code dann irgendwann damit korrekt läuft, ist alles in Butter?
Welche Version soll ich denn nehmen? Ich habe recht viele in der Liste, und bin nun nicht sicher, welche der SQL Server (Version 2005, Express) mitgebracht hat. Ich tippe auf 6.0? Ich müsste ja die nehmen, die dann - dank des gleichen SQL Servers - auch beim Kunden vorhanden sein sollte.
Und dann gibt es die 6.0 noch in einer Version "Multi-dimensional" und eine "Recordset"-Version. Was soll das denn sein?

Und zu guter Letzt: die MS Access Object Library bleibt aktiv, oder? Bin nicht ganz sicher, für welche Objekte die zuständig ist...

Danke für eure Hilfe,

Pete!
HannesB
access-muenchen.de


Verfasst am:
25. Sep 2009, 16:38
Rufname:
Wohnort: München


AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

DAO ist ok und seit der Version 2007 besser und sozusagen wiederauferstanden.
Die Arbeit mit einem SQL-Server kann problemlos (!) mit DAO erledigt werden.
Wenn schon ADO, dann ADO.net, was aber mit Access zumindest bis jetzt nicht in Sicht ist.

Die Probleme die man bei einem Umstieg der Daten auf einen SQL-Server hat, sind völlig anderer Art, zB. dass sich Access alle Daten vom Server nuckelt um dann lokal eine Abfrage auszuführen. usw.

Um auf deine Fragen einzugehen:
Die Datenzugriffsbibliothek DAO abhaken, dafür ADO mind. 2.7 auswählen.
Die anderen Bibliotheken sind nicht für den Datenzugriff zuständig.

Welche Gründe bewegen dich zum Umstieg?

_________________
Gruss,
Hannes
Speed Pete
Im Profil kannst Du frei den Rang ändern


Verfasst am:
29. Sep 2009, 14:21
Rufname:

Re: AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - Re: AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

HannesB - 25. Sep 2009, 16:38 hat folgendes geschrieben:
DAO ist ok und seit der Version 2007 besser und sozusagen wiederauferstanden.
Die Arbeit mit einem SQL-Server kann problemlos (!) mit DAO erledigt werden.
Aha - das wäre natürlich interesant. Ich denke jedoch nciht, dass der Kunde auf 2007 umsteigen will. Meine Frage bezieht sich ja auf 2003 - wie es da aussieht ist für mich interessant.

HannesB - 25. Sep 2009, 16:38 hat folgendes geschrieben:
Welche Gründe bewegen dich zum Umstieg?
Meine Literatur Very Happy . Ich habe zB dies gelesen:
Zitat:
[...]Ein wesentlicher Faktor ist beispielsweise, ob und in welchem Maße bei der Ausgangsdatenbank mit DAO programmiert worden ist. Dieser VBA-Code muss ja bekanntlich komplett auf ADO umgestellt werden.[...]
Das ist aber auch ein Buch zu Access 2002 und SQL Server 2000.
Sollte dies mit Access 2003 / SQL 2005 nicht mehr aktuell sein und ich kann mir das umprogrammieren sparen, wäre ich natürlich hoch erfreut... Laughing
MAPWARE
Access Profi(l)neurotiker


Verfasst am:
29. Sep 2009, 16:50
Rufname:
Wohnort: Hannover

AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Hi,

wenn Du nicht auf ein Access.Projekt sondern einfach nur auf eingebundene SQL Server Tabellen umsteigst, muss du fast gar nichts ändern. Bleib ruhig bei DAO oder nimm noch ein bisschen ADO dazu wenns passt. Dann ist auch die SQL Server Version ziemlich schnuppe. SQL 2000 bis SQL 2008 laufen problemlos, nur die ODBC Treiber ändern sich. Ich habe schon diverse Projekte mir eingebundenen SQL Server Tabellen realisiert, mit bis zu 50 gleichzeitigen Benutzern (Callcenter) und das lief und läuft völlig problemlos. ADO ist NICHT per se besser oder schneller. Es hängt alles an einem intelligenten Aufbau des Frontends und der Abfragen.

_________________
Grüße
Marcus

Wer Controls nicht sinnvoll benennt, wird es später bereuen.
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
29. Sep 2009, 17:31
Rufname:


AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Hallo Pete,

wenn Du nur "auf die Schnelle" eine Datenbank auf SQL Server umstellen willst und keine übermäßigen Ansprüche an die Datenbank stellst (z.B. Performance, Anzahl User usw.), was SQL Server Express ja vermuten läßt, dann genügt es völlig, bei ODBC verlinkten Tabellen und DAO zu bleiben - funktioniert gut und schnell, wenn Frontend und Backend gut aufeinander abgestimmt sind.

ADO ist nicht generell schneller, aber besser auf den SQL Server abgestimmt und ermöglicht Dir, den sehr immensen Overhead, den Access mit DAO und der Access-JET-Engine produziert, quasi auf Null zu reduzieren. Wenn Du mal sehen möchtest, was da passiert, solltest Du mal den SQL Server Profiler starten und die Kommunikation zwischen Access und dem Server anschauen... man könnte sagen, "erschreckend"...Smile

Ist aber auch kein Wunder, denn Access versucht hier, mit der Jet-Engine, die z.B. ganz andere Datentypen verwendet als der SQL Server, irgendwie die SQL Server spezifischen Dinge zu übersetzen, was viel Kraft und Zeit kostet und in einigen Fällen zu seltsamen Problemen führt.
Daher meine dringende Empfehlung: Wenn Du die Zeit und die Möglichkeit hast, lies Dich in ADO ein (ist nicht wirklich so viel anders als DAO, nur manchmal etwas mehr Schreibarbeit), stelle konsequent ALLES auf ADO um und insbesondere: Konvertiere das Access Frontend in ein Access Projekt. Ansonsten mußt Du nämlich andauernd mit zwei Technologien und Schreibweisen arbeiten: Einmal DAO und JET-Syntax, einmal ADO und SQL Server Syntax. Das ist fehleranfällig und nervenaufreibend - ich weiß, wovon ich spreche, ich bin gerade dabei, eine größere Datenbank genau auf diese Weise umzustellen.

Hast Du das Frontend in ein Access Projekt umgewandelt (am einfachsten: Projekt neu erstellen und dann alle Objekte aus der MDB importieren, dann anfangen, umzustellen), kannst Du ADO nämlich auch für alle RecordSources von Formularen und Berichten usw. verwenden, was mit einer MDB nicht (ohne weiteres) funktioniert. Darüber hinaus kannst Du komfortabel direkt auf alle vorhandenen Tabellen, Views, Stored Procedures, Functions usw. des Servers zugreifen, ohne alles erst mühsam einbinden zu müssen oder erneut einzubinden, wenn sich auf dem Server etwas ändert. Hier genügt ein Druck auf die F5-Taste, um die aktuellen Objekte des Servers zu sehen (oder ein Neustart der Datenbank).
Man muß sich etwas umgewöhnen, wenn es um die Verwendung von z.B. Stored Procedures als RowSource einer Kombobox geht, aber es geht in allen Fällen.

Und was man mit Stored Procedures und dessen Parametern machen kann, davon kann man als Access Programmierer nur träumen.

Und wenn Du ein paar grundsätzliche VBA-Funktionen suchst, mit denen Du per ADO im Code auf den Server zugreifen kannst, schau mal in das Tips&Tricks-Forum, dort habe ich eine kleine ADO-Library gepostet, mit der man sehr schnell und einfach mit ADO arbeiten kann, ohne in jeder Sub neu überlegen zu müssen, wie man nochmal ein Recordset öffnet usw:

ADO-Library sowie Memo-Felder in SQL Server 2005

(Das dort beschriebene Problem mit den Memo-Feldern gibt es übrigens bei Access Projekten auch nicht, da man 1:1 mit dem SQL Server arbeitet - und trotzdem den Komfort von Access hat.)

Gruß

Christian
Speed Pete
Im Profil kannst Du frei den Rang ändern


Verfasst am:
30. Sep 2009, 17:39
Rufname:

AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Wow! Vielen Dank für die ausführlichen Antworten. Ich werde mich mal ans Werk machen und bin gespannt...

Etwas oT, aber ich frag mal gerade: mein Porjekt unter Acc2003 gibt mir eine Fehlermeldung, wenn ich die Datensatzherkunft eines Formulares bearbeiten möchte:
Zitat:
Mit dieser Version von Name der Datenbank können keine Entwurfsänderungen vorgenommen werden, weil sie die Version von Microsoft SQL Server, mit der ihr Access-Projekt verbunden ist, nicht unterstützt."

Schluck! Welche Versionen wären denn kompatibel? Und vor allem: ist mir das egal und ich mache einfach für die Datensatzherkunft einen View im Management Studio? Oder birgt das Nachteile?
MAPWARE
Access Profi(l)neurotiker


Verfasst am:
30. Sep 2009, 20:04
Rufname:
Wohnort: Hannover

AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Hi,

tja, das ist einer der Gründe warum ich Access-Projekte nicht leiden kann. Jedes Update des SQL-Servers zwingt Dich möglicherweise zum Update der Access Umgebung. Wenn die Version nicht (mehr) passt, sind alle schicken Vorteile des Projektes flöten. Dann kann man, wie gesagt, auch bei einer Access MDB bleiben und statt der JET Engine einfach den SQL Server als Datenbank Engine mit eingebundenen Tabellen benutzen. Der Entwurf der Views (die man zur Leistungssteigerung früher oder später auch braucht) usw. geht eh besser im SQL Server Management Studio. Und noch ein kleines Argument, das für mich entscheidend war. Die Möglichkeit, auch VBA Funktionen in SQL-Abfragen zu benutzen, geht bei der Umstellung auf ein Access-Projekt verloren. Der SQL Server kennt halt kein VBA in seiner TSQL Syntax.

_________________
Grüße
Marcus

Wer Controls nicht sinnvoll benennt, wird es später bereuen.
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
30. Sep 2009, 20:04
Rufname:

AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Hallo Pete,

die Meldung kommt i.d.R., wenn Du als Login für den Server einen minderberechtigten Account in den Server-Eigenschaften angegeben hast. Das genügt zwar völlig, damit die User damit arbeiten können - aber so ein Account genügt nicht, um Objekte auf dem Server zu bearbeiten.

Für den Zeitraum der Entwicklung solltest Du daher einen Benutzer mit mindestens db_owner-Rechten verwenden, wenn Du die Datenbank dann auslieferst, kannst Du wieder einen "normalen" Useraccount nehmen.

Besser ist allerdings, die Serverobjekte auch ausschließlich mit dem SQL Server Management Studio zu entwickeln, daß einfach besser damit umgehen kann und mehr Möglichkeiten bietet.

Am besten ist es, die RecordSources als Views oder Stored Procedures anzulegen. In einem Access Projekt kann man dann die RecordSource wie eine normale Abfrage auswählen und einstellen. Das ist auch mit Stored Procedures möglich, Access Projekte bieten dazu eine neue Eigenschaft namens "Input Parameter" an, in die man die Parameter und ihre Werte in access-üblicher gewohnter Weise eingeben kann. Beispiel:

Code:
@MeinParameter=Forms![MeinFormular]!Feldname


So ist die Methode, die Access vorgibt - aber ich empfehle, sie nicht zu benutzen. Warum? Weil der Overhead-Unsinn von Access dann wieder losgeht, wenn auch nicht ganz so arg wie mit ODBC-Verbindungen.

Besser:
1. KEINE Views verwenden, IMMER Stored Procedures (denn Views können keine "ORDER BY"-Klausel verarbeiten, dies müßte wieder Access übernehmen, womit es wieder zu einem wilden Mischmasch kommt, der auch reichlich Performance kostet).
2. In den Stored Procedures (SPs) ORDER BY-Klauseln einfügen, soweit benötigt, außerdem Einschränkungen über WHERE festlegen, ggf. mit Parametern.
3. Im Form_Load-Event die RecordSource so setzen:
Code:
    Me.RecordSource = "EXEC [Schemaname].MeineStoredProcedure"
Diese Syntax veranlaßt Access dazu, diesen Befehl unverändert und ohne Overhead an den Server weiterzuleiten und dessen Ergebnis zu empfangen - dank SP bereits vorsortiert. Schneller geht's nicht.

Benötigt man irgendwelche Universalfilter (z.B. über eine Dropdown-Liste), legt man einfach einen Parameterwert und einen Anzeigewert in dieses Dropdownfeld und übergibt der SP diesen Parameterwert, z.B. so:
Code:
    Me.RecordSource = "EXEC [Schemaname].MeineStoredProcedure @MeinParameter='" & Me.MeinDropdownfeld & "'"
(in diesem Fall für einen Textwert)

So kann man die Stored Procedure auch vorgefilterte Listen liefern lassen, was ebenfalls weitaus schneller geht als die Access Filter zu verwenden (die man aber trotzdem weiterhin zusätzlich verwenden kann).

Natürlich kann die RecordSource für diese Methode auch in den Formulareigenschaften direkt eingestellt sein, solange man nicht wie im letzten Beispiel die Parameter erst dynamisch setzen muß (denn Access Syntax wie "Forms![MeinFormular]...." wird hier nicht unterstützt, da der String direkt an den SQL Server geht und dieser damit nichts anfangen kann).

Access erkennt übrigens auch bei dieser Methode korrekt, welche Felder die SP zurückgibt und zeigt diese in der Feldliste an.

4. kein dynamisches SQL verwenden.
Es gibt zwar im SQL Server über sp_executesql eine SP, mit der man dynamisches SQL ausführen kann (also einen SQL-String, der in der SP zusammengepuzzelt wird anhand von Parametern), aber bei dieser Möglichkeit geht Performance verloren, da der SQL Server solche Konstrukte nicht vorcompilieren und einen guten Ablaufplan erstellen kann.
Wo immer möglich, lieber den gleichen SQL-Befehl mit unterschiedlichen WHERE-Klauseln mehrfach in die SP schreiben und per IF-ELSEIF-Konstrukt den jeweils richtigen ausführen lassen - geht viel schneller, auch wenn es programmiertechnisch unschön aussieht. Wo immer durch Parameter möglich, sollte man natürlich einfach entsprechende Variablen einsetzen, wie etwa "WHERE MeinFeld=@MeinParameter".

Viel Spaß beim Experimentieren...Smile

Gruß

Christian
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
30. Sep 2009, 20:14
Rufname:

AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Hallo Marcus,

da muß ich widersprechen. Eben da liegt einer der besonderen Vorteile eines Access Projektes: Daß Du eben KEINEN Update der Access-Datenbank benötigst, wenn Du den Server wechselst. Alle Objekte, auf die der Login-Account Zugriff hat, stehen in einem Projekt sofort und vollständig zur Verfügung, bei einem verlinkten Zugriff muß JEDES verlinkte Objekt entfernt und neu eingebunden werden, damit es aktualisiert wird (bei DSN-loser Verlinkung). Auch so muß jedes Objekt aber erst aktualisiert werden, fügt man ein Feld in eine Tabelle ein, funktioniert bei MDB erst mal gar nichts mehr bei Zugriff auf diese Tabelle.

Darüber hinaus ist ein Serverwechsel natürlich nur innerhalb einer Version eines Servers sinnvoll, wechselt man etwa von SQL Server 2000 auf 2005, ist ohnehin eine Bearbeitung der Datenbank notwendig, da beide Server nun mal gewisse Dinge anders handhaben - nebenbei auch in den Objekten des SQL Servers. Beispielsweise kann man mit "SELECT TOP 100 PERCENT...ORDER BY..." bei 2000 noch eine View dazu überreden, eine sortierte Liste zurückzugeben, bei 2005 geht das nicht mehr. Usw.

Das Argument VBA-Funktionen in SQL Strings ist auch kein Problem: Die meisten der sinnvollen Funktionen von VBA sind bereits nur in anderer Schreibweise auch als Funktionen auf dem Server vorhanden, etwa "GetDate()" statt in VBA "Date()", um mal ein Beispiel zu nennen. Darüber hinaus kann man sich mit selbsterstellten Funktionen so richtig austoben und wem das noch nicht genügt, kann ein Assembly zusammenstellen, das in den SQL Server eingebunden wird (ab 2005) und ermöglicht, beliebige Funktionen in VB oder C zu schreiben.
Weitere VBA-Funktionen sind in SQL Befehlen ohnehin nicht gut, da sie lediglich reichlich Performance kosten und i.d.R. durch entsprechende Programmierung auf dem SQL Server zu ersetzen sind und dort weitaus schneller ausgeführt werden.

Gruß

Christian
MAPWARE
Access Profi(l)neurotiker


Verfasst am:
30. Sep 2009, 20:35
Rufname:
Wohnort: Hannover

AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Hallo Christian,

ich stimme Dir zu (uneingeschränkt) das ein richtiger, vollberuflicher Programmierer im Rahmen eines Business Projektes den Weg des Access Projektes gehen kann und sollte. Wenn es aber darum geht, eine vorhandene MDB mit überschaubaren Aufwand und unter Nutzung des Wissens, das dem typischen Nutzer dieses Forums zur Verfügung steht, auf einen SQL Server umzuziehen, würde ich weiterhin des Weg der eingebundenen Tabellen wählen.

Den Sourcecode, den es braucht um alle Objekte des SQL Servers beim Start der MDB neu einzubinden (DSNless) kann ich gerne zur Verfügung stellen.

Aber ich finde einfach, das im Access Projekt zu viele Dinge nicht mehr ohne VBA machbar sind. Gerade die Veränderungen in den Abfragen waren bei meinen ersten Versuchen zu schmerzhaft. Ist zwar lange her, aber ich erinnere mich gut daran.

Und wie gesagt die Access Version muss den SQL Server auch kennen, um die Vorteile zu nutzen. Access 2003 kennt anscheinend den SQL Server 2005 z.B nicht.

_________________
Grüße
Marcus

Wer Controls nicht sinnvoll benennt, wird es später bereuen.
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
30. Sep 2009, 23:43
Rufname:

AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Hallo Marcus,

das mit Access 2003 kann ich nicht sagen, da ich zur Zeit mit Access 2007 programmiere und es mit 2003 noch nicht ausprobiert habe. Denkbar wäre es, da 2005 ja nun mal nach 2003 war...Smile

Da der SQL Server 2005 aber mit 2000-Syntax und Objekten umgehen kann, wäre es denkbar, daß es trotzdem funktioniert.

Eine Funktion zum Einbinden von Objekten auf DSN-lose Weise ist in der o.g. ADO-Library auch vorhanden und heißt dort "RefreshLinkedTables" (weil ich bis vor kurzem auch noch die Datenbank per ODBC betrieben habe, aber wegen vieler kleiner Probleme nun auf ein Projekt umgestiegen bin und ich bin sehr froh darüber - es ist tatsächlich einfacher als mit der Jet-Engine dazwischen).

Welche Probleme Du allerdings mit den Abfragen hast/hattest, kann ich nicht so wirklich nachvollziehen. Der SQL Server tickt halt anders, man muß Abfragen etwas anders formulieren, aber gleichzeitig eröffnen sich einem mit T-SQL weitaus größere Möglichkeiten und Geschwindigkeiten als mit Jet-SQL und das sehe ich nicht als Nachteil, ganz im Gegenteil. Darüber hinaus muß sicherlich jeder selbst entscheiden, inwieweit er den Weg zum SQL Server geht, aber es ist empfehlenswert, es gleich richtig zu versuchen - mehr Aufwand am Anfang durch viele neue Dinge zu lernen, aber auch mehr Ergebnis, wenn man es einmal verstanden hat. Am Ende stellt man fest, daß man Access als Frontend durch geschicktes Auslagern der Funktionen auf den SQL Server irgendwann komplett durch beliebige andere Frontends wie Webfrontend oder Dot Net ersetzen kann.

Darüber hinaus finde ich, daß man einen SQL Server ohnehin nicht mit Access Makros programmieren sollte, ganz abgesehen davon, daß ich Makros auch nicht als vollwertige oder sinnvolle Programmieralternative ansehe, sobald es über die Verwaltung der heimischen Briefmarkensammlung hinaus geht.
Sind Anfänger Menschen, die man erst einmal mit ganz einfachen Dingen abspeist, um sie nicht abzuschrecken? Das mag wohl bei Microsoft so sein, die jetzt in Access 2010 den Makros einen deutlich verbesserten Editor und sogar einen Debugger verpaßt haben, statt ordentliche Arbeit in VBA zu investieren. Ich für meinen Teil finde, es besteht kein so riesiger Unterschied darin, ob man lernt, ein Programm als Makro zu schreiben oder per VBA - es funktioniert anders und Makros sind deutlich unleserlicher und unverständlicher und schwerer zu warten, aber sowas setzt man Anfängern vor. Warum?
Warum erst mit DAO und Jet hantieren, nur um doch irgendwann das SQL Management Studio nehmen zu müssen, um Views und Stored Procedures zu erstellen, um dann festzustellen, daß man sie mit DAO nicht aufrufen kann und man doch wieder ADO benötigt? Warum sich in vielen kleinen Schritten mühsam an etwas gewöhnen, was einem das Leben nicht einfacher macht, sondern nur ein bißchen Denkarbeit am Anfang abnimmt, durch Klickibunti und hübsche Assistenten?
Wer einmal den sinnvollen (!) Schritt gegangen ist, sich für SQL Server als Backend zu entscheiden, der sollte auch gleich den ganzen Schritt gehen und den Access-Jet-Ballast über Bord werfen und gleich richtig einsteigen. So schwer ist es nicht und wer sich nicht zutraut, mit dem SSMS umzugehen, der wird ohnehin lieber die Finger vom SQL Server lassen und bei Access als Backend bleiben. Aber wenn man schon den richtigen Schritt zu einer großen Datenbank macht, dann kann man auch gleich richtig beginnen und schon wird aus einem Anfänger ein Fortgeschrittener und irgendwann ein Profi.
Meine erste Datenbank war eine selbstgeschriebene auf dem C64 unter Verwendung des 1541-Floppy-Recordsystems. Da war noch nichts mit Maus und Formular zusammenschubsen. Na und? Solange es Handbücher gibt, kann man alles lernen, und von den damaligen sogenannten und selbsternannten "Profis" konnte man nichts lernen, da sie auf Anfänger immer milde lächelnd herabgesehen haben. Heute haben wir das Internet und jede Information ist sofort greifbar, also wo ist das Problem?
Ich sage: Auch den Anfängern eine Chance, solange sie sich bemühen und nicht alles vorgesetzt bekommen wollen.

Gruß

Christian
Speed Pete
Im Profil kannst Du frei den Rang ändern


Verfasst am:
01. Okt 2009, 11:46
Rufname:

AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Hmm - habe mich nun entschieden, einfach nur die Tabellen auf den Server zu legen und somit meine MDB so zu lassen wie sie ist. Warum?
- Der Kunde hat Access 2003 und legt wert auf ein modernes OS auf dem Server. Daher geht SQL 2005 nur mit Einschränkungen (wegen Acc2003, aber nur als Tabellenbackend ist es kein Problem) und SQL 2000 scheidet aus, da es schon unter Vista nicht mehr läuft.
- Grund des Umstiegs auf SQL ist nur die Sicherheit der Daten, die mit der Lösung "nur Tabellen auf den Server" ausreichend gegeben sein sollte.

Find's was schade, weil es spannend ist, aber ich werde mich einfach mal mit einem kleineren Projekt und in Ruhe in den SQL-Server einarbeiten.

Nach dem Upsizing (also nur dem Auslagern der Tabellen), läuft die Datenbank soweit gut. Aber ein Formular (das wichtigste) ist mir ein wenig zu lahm. Die Datenherkunft ist auch nicht von Pappe, da die Daten aus 4 Tabellen zusammengesucht werden müssen. Das wäre schön, wenn man das optimieren könnte.
Ich stieß oben auf dieses:
Zitat:
kannst Du ADO nämlich auch für alle RecordSources von Formularen und Berichten usw. verwenden, was mit einer MDB nicht (ohne weiteres) funktioniert.

Was heisst denn ohne weiteres? Ich könnte mir vorstellen, wenn ich zumindest diese eine Datenherkunft als View oder Stored Procedure auf dem Server haben könnte, dann wäre das Formular schon flotter...

Und wenn nicht: gibt es andere Anstäze, so was zu optimieren?
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
01. Okt 2009, 13:34
Rufname:

AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Hallo Pete,

die Anbindung einer ADO-RecordSource in einer MDB funktioniert nur als ungebundenes Recordset, mit XML-Fummelei, das ist den Aufwand nicht wert und schneller geht es auch nicht. Bin mir auch nicht sicher, ob es in Access2003 funktioniert.

Optimierungsmöglichkeiten gibt es meistens, bei Verwendung von SQL Server am besten, Deine Datenherkunft in einer Stored Procedure abzulegen, da hier auch Sortierung möglich ist und diese dann einzubinden, was mit ODBC schon recht schwierig ist. Einfacher geht es mit einer View, die man wie eine Tabelle einbinden kann, dafür aber ohne Sortierung, diese muß dann der Client (also Access) übernehmen.

Benötigt die Datenherkunft dynamisch zusammengefummelte Parameter, geht's am besten in VBA (wie gesagt, bei Verwendung einer MDB).

Darüber hinaus sollte man möglichst keine bedingte Formatierung in Endlosformularen einsetzen, die kosten die meiste Performance, insbesondere bei Verwendung von VBA-Funktionen und Einsatz von Filtern.

Es ist empfehlenswert, mit "MoveLast" und "MoveFirst" Access dazu zu zwingen, das ganze Recordset sofort zu laden, das geht deutlich schneller. Ebenso bei sehr langen Dropdowns mit "ListCount". Darüber hinaus sollte man in Endlosformularen, die nur der Anzeige dienen, generell keine Dropdowns verwenden, sondern ordentlich vorselektierte Spalten, ebenso nicht "SELECT *", sondern exakt nur die Spalten, die man wirklich braucht.
Nicht zuletzt kann auch ein sinnvoll eingesetzter zusätzlicher Index auf einer Tabelle einen guten Performancegewinn ausmachen.

Gruß

Christian
MAPWARE
Access Profi(l)neurotiker


Verfasst am:
01. Okt 2009, 13:44
Rufname:
Wohnort: Hannover

AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Hi,

bitte poste einmal die Datenquelle Deines Formulars, damit man sehen kann, was da die Performance beeinträchtigt.

Generell sind alle VBA Funktionen in Verdacht. Insbesondere iif() Format() Clng() und besonders die Domänenfunktionen da diese vom SQL Server nicht direkt ausgeführt werden können. Access holt dann oft alle Daten vom Server und führt die Joins dann selber durch. Das ist dann natürlich extra lahm.

_________________
Grüße
Marcus

Wer Controls nicht sinnvoll benennt, wird es später bereuen.
Speed Pete
Im Profil kannst Du frei den Rang ändern


Verfasst am:
01. Okt 2009, 16:04
Rufname:


AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO - AW: Grundsätzliche Tipps zu Umstellung DAO -> ADO

Nach oben
       Version: Office 2003

Die Datenquelle... da bin ich gespannt, ob ihr das Chaos durchblickt Very Happy . Ich versuche mal, es strukturiert zu schreiben:
Code:
SELECT   A.Auftrag_ID, A.RG_Nummer, A.[Eingabe durch], A.Buchungsdatum,
         A.Anreise, A.Abreise, A.Kommentar1, A.Kommentar2, A.TicketsRaus,
         A.TicketsAngefordert, A.Kurs_Nr, A.Kunden_ID, A.Familie_ID,
         A.Gesamtnote, A.FeedbackAufgefüllt, K.KD_ID,
         Trim([KD_Titel] & " " & [KD_Vorname] & " " & [KD_Nachname]) & Chr(13)
         & Chr(10) & [KD_Straße] & Chr(13) & Chr(10) & [KD_PLZ] & " "
         & [KD_Ort] & Chr(13) & Chr(10) & Chr(13) & Chr(10) & "Fon: "
         & [KD_Telefon] & Chr(13) & Chr(10) & "Dienst: " & [KD_TelDienst]
         & Chr(13) & Chr(10) & "Handy: " & [KD_Handy] & Chr(13) & Chr(10)
         & "Fax: " & [KD_Fax] & Chr(13) & Chr(10) & "eMail: "
         & [KD_EMail] AS KD_Info,
         [FA_Name] & Chr(13) & Chr(10) & [FA_Name2] & Chr(13) & Chr(10)
         & Trim([FA_Titel] & " " & [FA_Vorname] & " " & [FA_Nachname])
         & Chr(13) & Chr(10) & [FA_Straße] & Chr(13) & Chr(10) & [FA_PLZ]
         & " " & [FA_Ort] AS FA_Info,
         [KD_CreditcardNummer] & Chr(13) & Chr(10)
         & [KD_CreditcardVerfallMonat] & " / "
         & [KD_CreditcardVerfallJahr] AS KD_CreditCard, A.Reisebüro,
         A.Kredit_Nummer, K.KD_CreditcardNummer, K.KD_CreditcardVerfallMonat,
         K.KD_CreditcardVerfallJahr, I.Kurs_Nummer, I.Kurs_Zentrum,
         I.Kurs_Unterbringung, A.Kurs_Sonderwunsch, G.Familie_Name,
         G.Familie_Straße, G.Familie_Ort, G.Familie_Telefon,
         G.Familie_Kommentar, A.Alt_Kennummer, A.Alt_CCAB, A.Alt_CCAnz,
         A.Alt_BezEZ, A.Alt_BezAZ, A.Kredit_AblaufMonat, A.Kredit_AblaufJahr,
         A.Vorlage, A.RG_AZBezahlt, A.RG_EZBezahlt, A.RG_AZAuto,
         A.RG_AnzahlungWert, A.Kredit_AutorisierungAZ,
         A.Kredit_AutorisierungEZ, A.KD_Referenz, A.Englisch, A.FirmenRG,
         A.Kurs_Accomodation, K.KD_EMail, K.KD_Bemerkung
FROM     Gastfamilien AS G
         RIGHT JOIN (Kursinfos AS I
                     RIGHT JOIN (Kunden AS K
                                 RIGHT JOIN Aufträge AS A
                                 ON K.KD_ID = A.Kunden_ID)
                     ON I.Kurs_ID = A.Kurs_Nr)
         ON G.Familie_ID = A.Familie_ID
WHERE    A.Vorlage=No
ORDER BY A.Auftrag_ID;
(Hab absichtlich mal keine Felder gekürzt, um auch den Umfang abschätzen zu können.)
Dazu kommen noch 4 Felder mit komplexeren Berechnungen. Sie sind alle sehr ähnlich, daher nur eines hier als Beispiel:
Code:
=DomSumme("[RG_Preis]";"[Rechnungsposten]";"[AU_Nummer] = " & [Auftrag_ID])-[RG_AnzahlungWert]
Und dann hat das Formular noch 3 UFos. Da ist die Herkunft jeweils eine Tabelle, die eben über die Schlüsselfelder verknüpft wird.
Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Gehe zu Seite 1, 2  Weiter
Diese Seite Freunden empfehlen

Seite 1 von 2
Gehe zu:  
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Verwandte Themen
Forum / Themen   Antworten   Autor   Aufrufe   Letzter Beitrag 
Keine neuen Beiträge Access Tabellen & Abfragen: SQL einer View mit ADO nach Excel überführen 2 Volkwin 184 03. Sep 2013, 10:01
Blackpit2013 SQL einer View mit ADO nach Excel überführen
Keine neuen Beiträge Access Formulare: Formulargestaltung grundsätzliche Machbarkeit? 10 relaxo 391 14. Sep 2012, 09:45
relaxo Formulargestaltung grundsätzliche Machbarkeit?
Keine neuen Beiträge Access Formulare: Umstellung des Filters im Unterformular 14 s_Techert 184 18. Okt 2011, 13:44
Gast Umstellung des Filters im Unterformular
Keine neuen Beiträge Access Tabellen & Abfragen: ENVIRON() Umstellung XP/off2000 auf Win7/off2010 14 PetraS 1606 04. Jul 2011, 09:27
steffen0815 ENVIRON() Umstellung XP/off2000 auf Win7/off2010
Keine neuen Beiträge Access Tabellen & Abfragen: Grundsätzliche Frage zum regelmäßigen Datenimport 1 eichhörnchen2020 187 15. Dez 2010, 00:50
redround Grundsätzliche Frage zum regelmäßigen Datenimport
Keine neuen Beiträge Access Berichte: Tipps zur Gestaltung 0 Dille 280 26. März 2010, 10:20
Dille Tipps zur Gestaltung
Keine neuen Beiträge Access Tabellen & Abfragen: Importieren von CSV über Access ADO nach MS SQL Server 5 Neuendorf 1393 13. Jan 2010, 11:23
Gast Importieren von CSV über Access ADO nach MS SQL Server
Keine neuen Beiträge Access Formulare: Kalenderprobleme nach Umstellung Access 2003 zu Access 2007 2 Marioo 1493 09. Jan 2009, 18:31
Nouba Kalenderprobleme nach Umstellung Access 2003 zu Access 2007
Keine neuen Beiträge Access Programmierung / VBA: nach Umstellung auf A2003 -> andere err.number 0 Uwe Schönfeld 604 27. Jan 2006, 15:04
Uwe Schönfeld nach Umstellung auf A2003 -> andere err.number
Keine neuen Beiträge Access Programmierung / VBA: Problem ACCESS--> WORD nach Umstellung von off. 2000--> 1 georgia 588 10. Nov 2005, 23:06
georgia Problem ACCESS--> WORD nach Umstellung von off. 2000-->
Keine neuen Beiträge Access Programmierung / VBA: ADO leere Fehlermeldung 0 KobraKhan 603 08. Nov 2005, 23:52
KobraKhan ADO leere Fehlermeldung
Keine neuen Beiträge Access Programmierung / VBA: ADO rs.Find mit mehreren Kriterien? 4 vfrei 4849 06. Jun 2005, 16:48
vfrei ADO rs.Find mit mehreren Kriterien?
 

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: PHP Forum