Re: Union-Abfragen, Geschwindigkeit beim Speichern, Access oder SQL-Server

From: Peter Götz (gssg_nospam_at_t-online.de)
Date: 03/30/04 

Date: Tue, 30 Mar 2004 10:31:26 +0200

Hallo Matthias,

>
> Dann kann ich aber nicht anbieten eine Auswertung über alle Daten
> (aktuelle und archivierte) zu erstellen.

Ich kann nicht beurteilen, ob eine solche Auswertung überhaupt nötig und
sinnvoll ist.
Wenn wirklich eine Auswertung über einen Zeitraum von mehreren Jahren
erforderlich ist, dann hilft es natürlich wenig, wenn die Daten auf
verschiedene CDs mit jeweils einem Jahresvolumen an Daten verteilt sind.

> Ich hätte ja noch die Möglichkeit, das Archiv in eine andere Datenbank
> auszulagern und nur bei Bedarf die Tabelle Archiv in die aktuelle
> Datenbank einzubinden/verknüpfen. Die Verknüpfung könnte ich dann nach
> Beendigung der Abfrage wieder aufheben.

Archiv meint eben normalerweise, dass die archivierten Daten nicht unbedingt
"online" zur Verfügung stehen, sondern eben irgendwo in einem Panzerschrank
auf einem Datenträger schlummern.

> Wird denn beim Speichern von Datensätzen eine Abfrage in Access auch
> aktualisiert oder nur die Tabelle? Werden die Datensätze, die von einer
> Abfrage tangiert werden erst bei Aufruf/Öffnen der Abfrage zusammen
> gestellt?

Ich weiss nicht so recht, was Du im konkreten Fall mit Abfrage meinst?
Bei Access kannst Du ähnlich wie beim SQL-Server vorgefertigte Abfragen
(SQL-Statements) in der Datenbank selbst hinterlegen. Über den Namen einer
solchen Abfrage kann diese ausgeführt werden. Der SQL-Server als aktives
System kann selbst dieses SQL-Statement aus der DB lesen, es interpretieren
und dann ausführen. Sprich der SQL-Server wird, nachdem er das zu dieser
Abfrage gehörende SQL-Statement ausgeführt hat, die daraus resultierende
Anzahl von Datensätzen zum Client schicken.
Eine Access.mdb ist kein aktives System, sondern eine simple passive Datei.
Eine Datei kann von sich aus kein SQL-Statement lesen, es interpretieren
oder ausführen. Beim Zugriff auf eine Access.mdb über die Jet-Engine laufen
Dinge die der SQL-Server bei gespeicherten Prozeduren macht, innerhalb der
Jet-Engine ab. Die Jet-Engine läuft aber nicht auf dem Server, sondern eben
in jedem einzelnen Client.

Eine in einer Access.mdb gespeicherte Abfrage ist im Grunde nichts weiter
als ein in dieser *.mdb gespeicherter Text eines SQL-Statements. Die
Jet-Engine (beim Client) kann dieses SQL-Statement aus der DB herauslesen,
es interpretieren und dann die dazu passende Anzahl von Datensätzen aus der
*.mdb herauslesen. Sofern dabei passend indizierte Felder zur Verfügung
stehen, kann die Jet-Engine dabei sehr ökonomisch vorgehen und auch wirklich
nur die benötigten Datensätze aus der/den Datenbanktabelle(n) herauslesen.

Man liest immer mal wieder Behauptungen, dass die Jet-Engine erst den Inhalt
der gesamten Tabelle einlesen müsste um dann daraus die der im SQL-Statement
enthaltenen Where-Klausel entsprechenden Datensätze herauszufiltern. Bei
halbwegs intelligenter Indizierung der richtigen Felder ist das keineswegs
so. Die Jet-Engine wird da meist gewaltig unterschätzt.

> Wo werden die Daten der Abfrage zusammengestellt? Auf dem Server, d.h.
> macht das Access oder erst in der Anwendung? Werden also erst alle Daten
> auf den Client übertragen und da dann die "aussortiert", die in das
> entsprechende Recordset gehören?

s.oben.
Vorausgesetzt die in der Where-Klausel des auszuführenden SQL-Statements
sind passend indiziert, dann kann die Jet-Engine ganz gezielt und selektiv,
nur die tatsächlich benötigten Datensätze aus der *.mdb herauspicken und
auch wirklich nur diese zum Client hin einlesen. Es muss keineswegs die
gesamte Tabelle von der *.mdb zum Client übertragen werden.

> Hier vermute ich den Unterschied zwischen in Access gespeicherten
> Abfragen und solchen die ich per SQL in meiner Anwendung habe.

Der Unterschied ist eigentlich gar nicht so gross.
Beim SQL-Server läuft halt einfach der aktive Teil des DB-Systems, also das
Programm, welches die SQL-Statements interpretiert und ausführt auf dem
Server. Die Clients schicken ihre Anforderungen zu diesem Programm. Dieses
Programm greift dann entsprechend der Anforderung auf die eigentliche(n)
DB-Datendatei(en) zu, liest die angeforderten Daten dort heraus und übergibt
sie dem jeweiligen Client. Hat ein Client einen Befehl geschickt, der nur
Daten ändert oder löscht, aber keine Daten zurückerwartet, wird das Programm
SQL-Server eben genau diesen Befehl ausführen und nach Abschluss eben nur
den Erfolg oder Misserfolg der Operation zurückmelden.

Die Jet-Engine ist ein mit dem SQL-Server vergleichbares Programm. Nur läuft
dieses Programm eben nicht auf dem Server, sondern auf dem jeweiligen
Client. Wenn die Jet-Engine auf Daten in der *.mdb zugreifen will, liegen
eben diese Daten nicht unbedingt auf dem gleichen Rechner, sondern eben
irgendwo auf einem Server im LAN oder notfalls auch weiter weg.
Wenn nun ein Programm, welches auf dem Client läuft, Daten aus einer
Access.mdb braucht, schickt es die entsprechende Anforderung (SQL-Statement)
an das ebenfalls auf dem Client laufende Programm Jet-Engine. Die Jet-Engine
interpretiert das SQL-Statement und führt dann (übers LAN) genau die dafür
erforderlichen Lesezugriffe auf die *.mdb aus. Möchte das DB-Programm
irgendwelche Datensätze ändern oder löschen, schickt es die entsprechenden
SQL-Statements an die Jet-Engine, diese interpretiert auch das wieder und
ändert oder löscht dann eben die gewünschten Datensätze.

Im Grunde läuft bei der Jet-Engine beim Zusammenspiel mit einer *.mdb das
Selbe ab, was beim SQL-Server eben auf dem Server beim Zusammenspiel
zwischen der DB-Engine des SQL-Servers und den vom SQL-Server verwalteten
Datendateien abläuft.

Bei der Jet-Engine in Verbindung mit *.mdb ist eben nur der Weg zwischen dem
aktiven Programm (DB-Engine) und den Datendateien länger (sofern die *.mdb
nicht auf dem Client liegt).

Dabei ergibt sich natürlich auch noch ein weiterer Effekt.
Der SQL-Server bekommt Anfragen von Clients und stellt die, wenn er gerade
keine Zeit hat in einen Zwischenspeicher (Puffer). Dort können eine ganz
Menge solcher Anfragen in die Warteschlange gestellt werden und von dort
aus, dann der Reihe nach abgearbeitet werden. Dass das Programm SQL-Server
gerade was anderes zu tun hat, merken die Clients eigentlich nur daran, dass
die Antwort auf eine gestellt Anfrage möglicherweise etwas länger dauert.

Bei der Jet-Engine, die im Speicher des Clients abläuft, sieht das etwas
anders aus. Wenn die einen Datensatz lesen oder schreiben will, dann kann es
passieren, dass gerade eine auf einem anderen Client laufende Jet-Engine an
der *.mdb etwas ändert. Für die erste Jet-Engine bedeutet dies, dass sie
erkennt, dass die *.mdb gerade anderweitig belegt ist und sie löst deshalb
einen Fehler aus. Dieser Fehler muss von dem aufrufenden Programm
ausgewertet werden. Das könnte z.B. so aussehen, dass das aufrufende
Programm in diesem Fall einige Millisekunden wartet und dann den gerade
misslungenen Befehl nochmal an die Jet-Engine schickt.

Der Unterschied zum SQL-Server ist also der, dass bei diesem eigentlich ein
Konfliktfall (mehrere Programme wollen auf die selbe Datei zugreifen) gar
nicht vorkommen kann, da ja nur ein einziges Programm, nämlich die DB-Engine
des SQL-Servers direkten Zugriff auf die Datendatei(en) der SQL-Server DB
hat.
Bei einer *.mdb gibt es in den meisten Fällen kein zentrales Programm,
welches nur allein Zugriff auf die darin befindlichen Daten hat. Jedes
x-beliebige Programm, nicht nur eine Jet-Engine, kann auf diese Datei
zugreifen. Wird die Datei gerade von einem anderen Programm bzw. anderen
Client bearbeitet, wird das wie bei jeder anderen Datei auch, erkannt und
führt zu einem Fehler, der dann eben entsprechend behandelt werden muss. Die
Fehlerbehandlung ist also bei der Zusammenarbeit mit der Jet-Engine ein ganz
zentraler Punkt und erfordert einen entsprechend hohen Programmieraufwand.

>
> Wie geht hier ein SQL-Server vor? Ist es hier so, daß ich z.B. durch
> stored prozedures die benötigten Datensätze auf dem Server
> zusammenstellen lassen und nur das Ergebnis auf den Client übertragen
> kann?

Ja.
Das aktive Programm SQL-Server bekommt vom Client den Auftrag irgendeine
gespeicherte Prozedur auszuführen. Der SQL-Server stellt diesen Auftrag in
seinen Puffer und wenn er dann irgendwann mal Zeit hat, führt er diesen
Auftrag aus und liefert genau die daraus resultierenden Daten an den
jeweiligen Client zurück.

> Der SQL-Server ist doch eine "aktive" Datenbank im Gegensatz zu z.B.
> Access, die eine passive Datenbank ist. Was sind die Aktivitäten, wo
> also die Vorteile?

Der Vorteil ist, dass nur ein einziges Programm, nämlich der SQL-Server
selbst Zugriff auf die eigentlichen Daten hat. Kein anderes Programm hat die
Erlaubnis, direkt an den Daten etwas zu ändern oder diese zu lesen. Jeder
Zugriff auf die Daten läuft immer erst über das Programm SQL-Server. Dieses
Programm stellt die von den verschiedenen Clients kommenden Aufträge in
einen Puffer und arbeitet sie dann von dort der Reihe nach ab. Es kann also
gar nicht vorkommen, dass zwei Programme oder eben zwei Clients gleichzeitig
auf die selben Daten zugreifen.

> Fachbücher, die darüber etwas aussagen habe ich bisher nicht gefunden.

Zumindest deutschsprachige Bücher wirst Du vermutlich vergeblich suchen. Was
ich bisher so an deutschsprachigen Büchern zum Thema Datenbanken gelesen
habe, war nicht wirklich weltbewegend.

> Woher bekomme ich Informatioenn/Literatur, die z.B. Access und SQL-
> Server gegenüberstellen? Gibt es so etwas überhaupt?

Ich bin nicht sicher ob so etwas wirklich sinnvoll wäre.
Du musst einfach verstehen, dass ein SQL-Server nicht nur eine zentrale
Datei ist, in der irgendwelche Daten abgelegt werden, sondern dass der
SQL-Server auch noch ein Programm beinhaltet, welches diese zentrale
Datendatei(en) ganz alleine verwaltet.
Eine Access.mdb dagegen ist kein Programm, sondern eben nur eine simple
zentrale Datei in der einer oder mehrere Clients ihre Daten ablegen können.

Im Prinzip kannst Du Dir natürlich mit einer *.mdb und einem Programm,
welches auf dem Server läuft einen SQL-Server nachbauen. Dieses Programm
kann über die Jet-Engine auf eine Access.mdb zugreifen. Zur anderen Seite
hin, also zum LAN, stellt dieses Programm Schnittstellen bereit, über welche
die Clients Datenanforderungen bzw. Befehle an dieses auf dem Server
laufende Programm senden und entsprechende Daten zurückerhalten. Die Clients
bekommen also keinen direkten Zugriff auf die *.mdb mehr, sondern müssen dem
auf dem Server laufenden Programm, genauso wie dem SQL-Server, erst mal
sagen, was sie haben wollen. Das zentrale Programm geht dann ans Regal (die
eigentlichen Daten in der *.mdb) sucht das gewünschte heraus und gibt es
dann dem anfordernden Client.

>
> > Möchte jemand ältere Daten aus so einem Archiv
> > mal einsehen, schiebt er die entsprechende CD in sein Laufwerk und
> > öffnet mit dem ganz normalen Programm die auf dieser CD befindliche
> > *.mdb.
>
> Da kann ja keine *.ldb angelegt werden. Klappt das trotzdem oder muß die
> DB von der CD kopiert werden?

Bei einem Archiv wird man in der Regel nur lesend zugreifen.
Öffnet man eine *.mdb exklusiv, dann wird keine *.ldb benötigt, da durch das
exklusive Öffnen der *.mdb von allen anderen evtl. zugreifenden Clients
sofort erkannt wird, dass die *.mdb momentan nicht verfügbar ist.
Man öffnet die Archiv-DB also einfach im Exclusiv-Modus, liest die
gewünschten Daten und schliesst sie wieder. Das geht ganz ohne *.ldb.

>
> Was passiert bei einer Weiterentwicklung der Anwendung? müssen dann die
> Archivdatenbanken auch upgedatet und neu auf CD gebrannt werden?

Das kommt auf die Art der Weiterentwicklung an, sprich darauf, ob und was Du
an der Datenstrukur innerhalb der DB änderst. Wenn Du grundlegende
Änderungen an der Struktur der DB vornimmst, ist es egal ob das bei einer
*.mdb, bei einem SQL-Server oder einem sonstigen DB-System geschieht. Es
wird in jedem Fall an irgend einer Stelle Programmänderungen erfordern.

> Kannst Du so gewährleisten, daß die Daten auch in 15, 20 Jahren oder
> sogar 30 Jahren noch einsehbar sind - z.B. bei Betriebssystemwechsel,

Natürlich nicht.
Aber auch da macht es keinen Unterschied ob die Daten in einer SQL-Server DB
oder in einer *.mdb gespeichert sind. Die Chance die Daten aus einer auf
einer CD in einer *.mdb in 20 Jahren noch herauszulesen sind eher grösser
als bei Daten die in einem SQL-Server gespeichert sind.

> Weiterentwicklung der Hardware usw.? Ich kenne alte Clipperprogramme
> (Dbase), die auf neuer Hardware nicht mehr laufen, weil die Hardware zu
> schnell ist.

Na ja, das sind aber Dinge, die nun wirklich der Vergangenheit angehören.
Ein alter SQL-Server 6.5 oder eine ältere Version der Jet-Engine laufen auch
auf modernen schnellen Rechnern in der Regel ohne Probleme.

> Man kann den Kunden ja nicht zumuten, sich irgendwo noch
> einen Oltimer hinzustellen, nur um evtl. mal alte Daten einsehen zu
> können. Und auch ein Oltimer geht mal kaputt, was dann?

Das ist auch gar nicht nötig.
Das Programm, welches die *.mdb von einer CD liest, muss eben auf em
jeweiligen System laufen. Ob das System nun alt oder neu ist, spielt keine
Rolle. Auf dem neueren wird es vermutlich schneller laufen. Aber dagegen ist
ja kaum was einzuwenden. Ansonsten verstehe ich nicht so recht, wo Du da ein
Problem siehst.
Wenn irgendwann mal ein xxx-Bit Betriebssystem auf den Markt kommt, das zum
bisherigen Windowsstandard nicht mehr kompatibel ist, wird auf einem solchen
Systmem weder ein SQL-Server noch eine Jet-Engine mehr laufen. Also ist es
so gesehen erst mal völlig egal ob Du mit der Jet-Engine oder dem SQL-Server
arbeitest.

> Die Tabelle Archiv wird doch von neuen Datensätzen nicht berührt. Für
> die Archvierung wird es eine eigene Form geben, die die Aufgabe des
> "verschiebens" der Datensätze Usergesteuert übernimmt - oder was meinst
> Du mit zwei Tabellen?

Genau das ist eben der Witz bei einem Archiv, welches genau die selbe
Datenstruktur wie die tagesaktuelle DB hat. Man braucht kein zusätzliches
Programm oder zusätzliche Forms um damit auf das Archiv zuzugreifen. Exakt
das selbe Programm mit den selben Forms kann die aktuelle *.mdb und eine
irgendwo aus dem Panzerschrank geholte CD mit einer darauf befindlichen
Archiv.mdb lesen.

>
> > > 3. Ist es grundsätzlich so, daß viele unterschiedliche in Access
> > > gespeicherte Abfragen die Datenbank langsamer machen, weil beim
> > > Speichern immer die betroffenen Abfragen auch aktualisiert
> > > werden?

Da wird nichts aktualisiert.
Eine in einer *.mdb gespeicherte Abfrage ist im Grund nichts weiter als ein
vorgefertigtes SQL-Statement. Die Jet-Engine kann dieses Auslesen, es mit
entsprechenden Parametern bei sich selbst vervollständigen und dann die
daraus resultierende Abfolge von Befehlen ausführen. An der in der *.mdb
gespeicherten Abfrage ändert sich dabei überhaupt nichts.

> Das habe ich jetzt (hoffentlich) verstanden. Bisher habe ich z.B. für
> die Tabelle T_Kunden auch Abfragen gespeichert, die alle Datensätze der
> Tabelle umfassen und nur anders sortieren.

Viel einfacher und effizienter ist es, die gesamte Datenmenge erst mal in
ein Recordset mit clientseitigem Cursor einzulesen. Die Daten liegen nun im
Speicher des Clients. Und nun kann man bei ADO per Recordset.Sort die
Sortierung mit beeindruckender Schnelligkeit beliebig ändern, ohne dafür
auch nur noch ein einziges mal auf die Datenbank zugreifen zu müssen. Und
wenn es dem Benutzer einfällt die Sortierung seines Recordsets im
Sekundentakt zu ändern, dann berührt das die Datenbank (*.mdb) überhaupt
nicht. Sie erfährt davon noch nicht mal was.

> Dann habe ich, wenn der
> Anwender die Sortierung gewechselt hat z.B. von "nach Name" auf "nach
> PLZ" das Recordset einfach geändert von der Abfrage "A_Kunden_Name" auf
> "A_Kunden_PLZ". Dieses Vorgehen ist also eher als unglücklich zu
> bewerten. Besser wäre es, den SQL im Programm zusammenzustellen.
> Richtig?

Nein, siehe oben.
Daten einmal einlesen und dann nach Belieben im Speicher des Clients selbst
die gewünschte Sortierung herstellen.
Dazu ist es aber erforderlich, dass Du den Unterschied zwischen Recordsets
mit serverseitigem und Recordsets mit clientseitigem Cursor verstanden hast.
Serverseitige Cursor sind in aller Regel reine Ressourcenverschwendung und
es gibt nur sehr, sehr wenige Fälle in denen wirklich ein serverseitiger
Cursor erforderlich wäre. Scheinbare Probleme die vermeintlich nur mit
serverseitigem Cursor zu lösen sind, lassen sich bei genauerem Hinsehen
meist doch mit clientseitigem Cursor und dann meist auch deutlich
ökonomischer lösen.

> > Den stabileren und auch übersichtlicheren Betrieb erreichst Du mit
> > SQL-Statements die in Deinem Programmcode generiert werden.
> > Ansonsten siehe den vorigen Absatz.
>
> ich denke das ist mir jetzt klar. Aber warum ist es stabiler?

Weil Du nicht erst ein SQL-Statement aus der *.mdb herauslesen musst um dann
erneut ein weiteres mal auf die DB zuzugreifen um die im SQL-Statement
enthaltenen Befehle auszuführen. Jeder Zugriff auf die *.mdb beinhaltet das
Risiko, dass es einen Zugriffskonflikt mit einem anderen Client gibt. Dieser
Zugriffskonflikt löst einen Fehler aus, der im Programm behandelt werden
muss. Weniger Zugriffe bedeuten automatisch ein geringeres Risiko von
Konflikten und Dein Programm wird sich mehr auf die eigentliche Aufgabe und
nicht vorrangig auf die Fehlerbehandlung konzentrieren können.

> Meine Kollegen bekomme manchmal (sehr selten, aber es passiert schon
> mal) den Fehler "3021 kein Datensatz ausgewählt". Wenn ich dann die
> Anwendung schließe und neu öffne, geht's. Meinst Du evtl. solches
> Verhalten?

Nein.
Der 3021 wird dann ausgelöst, wenn der Datensatzzeiger Deines Recordsets auf
BOF oder EOF steht und Du z.B. so was machst

    Dim lngWert as long
    lngWert = RS.Fields(x).Value

Es kommt zum Fehler 3021, wenn der Datensatzzeiger des Recordsets nicht auf
einen gültigen Datensatz zeigt. Also wenn z.B. RS.BOF oder RS.EOF ist.
Zu einem solchen Fehler kann es eigentlich nur in einem unsauber
programmierten Programm kommen. Bevor man im Code auf Daten eines
Datensatzes zugreift, sollte man immer prüfen oder anderweitig
sicherstellen, dass der Datensatzzeiger auch wirklich auf einen gültigen
Datensatz zeigt.

    Select Case True
        Case RS is Nothing
        Case (RS.State and adStateOpen) = adStateOpen
        Case RS.BOF or RS.EOF
        Case Else
            ' sofern Du in Deinem Programmcode konsequent _
             dafür sorgst, dass der Datensatzzeiger nach dem _
             Löschen eines Datensatzes von diesem wegbewegt _
             wird, kannst Du an dieser Stelle sicher sein, dass RS _
             existiert, geöffnet ist und auf einem gültigen _
             Datensatz steht.
    End Select

> > > 1. So weit ich weiß, ist der Vorteil von MS SQL-Server gegenüber
> > > Access "nur", daß der SQL-Server größere Datenmengen / Datenbanken
> > > verwalten kann und serverseitige Clients unterstützt, was die
> > > Netzlast ver-
> >
> > "serverseitige Clients"?
>
> Schreibteufel! Natürlich meinte ich serverseitige Cursor. (was ist das
> genau, könntest Du mir da auf die Sprünge helfen?

Es ist ein weitverbreiteter Irrglaube, dass serverseitige Cursor die
Netzlast verringern würden. Es ist zwar richtig, dass bei serverseitigem
Cursor bei einem einzigen Zugriff meist weniger Daten übers Netz
transportiert werden müssen. Es sind aber sehr viel mehr solcher Zugriffe
als bei clientseitigem Cursor erforderlich. Bei jedem dieser Zugriffe kommen
zu den eigentlichen Nutzdaten Verwaltungsdaten des DB-Systems und des
Übertragungsprotokolls (z.B. IP) hinzu.

Bei clientseitigen Cursor wird einmal eine grössere Datenmenge zum Client
übertragen und dann ist erst mal für eine lange Zeit absolute Ruhe auf dem
LAN und beim Server.

> Gibt es neben der Grenze von 2 GB noch Grenzen für einzelne Tabellen?
> Ich meine nicht die Grenze von 255 Feldern pro Tabelle sondern Anzahl
> Datensätze pro Tabelle.

Die 2 GB Grenze ist entscheidend, nicht die Anzahl der Datensätze.
Ich habe Anwendungen laufen, in denen mehrere Millionen Datensätze in einer
Tabelle anfallen. Für die Jet-Engine ist das absolut kein Problem.

> Die Frage, ob die Nutzung einer SQL-Datenbank schneller ist.

Das kommt auf die Art der Anwendung und nicht zuletzt auf die Anzahl der
gleichzeitig zugreifenden Anwender an. In vielen Fällen wird die *.mdb die
deutlich schnellere Variante sein, in anderen Fällen und vor allem bei sehr
vielen (z.B. einige hundert) gleichzeitigen Benutzern wird der SQL-Server im
Vorteil sein.

Eine Access.mdb erfordert keinerlei Wartungsaufwand. Das ist eine simple
Datei wie jede andere auch.
Ein SQL-Server ist ein System das nicht jeder Hinz und Kunz warten und
pflegen kann. Da sollte schon ein halbwegs geschulter Administrator
vorhanden sein.

>
> Außerdem möchte ich die Situation und Fragestellung meines Chefs nutzen,
> mich selbst zu informieren. Ich habe noch immer Schwierigkeiten, die
> Vorteile von SQL-Servern grundsätzlich zu verstehen.

Ich denke das ist die falsche Betrachtungsweise.
Man kann nicht sagen, der SQL-Server ist besser oder umgekehrt eine
Access.mdb ist besser. Verwende für jeden Zweck das richtige, passende
DB-System. Das kann in einem Fall die *.mdb mit einer Jet-Engine und im
anderen Fall der SQL-Server oder eine MSDE sein.

> Wie Du oben
> schreibst, machen Clientcursor auch bei einem SQL-Server Sinn. Logisch,
> wenn ich Daten ändern möchte, da muß der Client ja die Kontrolle haben.

Nein nicht vorrangig wegen irgendwelcher Kontrolle.
Clientseitige Cursor und ein geschicktes Programmkonzept können ganz einfach
die Anzahl der Zugriffe auf die DB und somit auch die Server- und Netzlast
ganz deutlich minimieren. Ein LAN in dem jedes zweite Datenpaket zu einer
Kollission führt ist eben kein schnelles LAN mehr.

> Aber bei reinen Abfragen, Auswertungen? Ich habe selbst das Gefühl, mich
> undeutlich auszudrücken, aber wo soll ich anfangen?

Schau Dir die Dokumentation zur Jet-Engine, zu ADO und die Dokumentation zum
SQL-Server gründlich an. Das ist eine Menge Zeug zum Lesen. Aber die Mühe
musst Du Dir antun, wenn Du wirklich verstehen willst, wie und was die
verschiedenen DB-Systeme arbeiten.

> > > 4. Falls ein solcher Umstieg in Betracht kommt, macht es dann Sinn
> > > das bestehende Projekt auf SQL-Server bzw. Alternative umzusetzen
> > > oder wäre eine Neuprogrammierung unter VB-Net vorzuziehen. Mir ist

Auch bei VB.net nimmt Dir die Entscheidung für das eine oder andere
DB-System niemand ab. Auch bei VB.net kannst Du mit der Jet-Engine, dem
SQL-Server, mit Informix, Oracle oder irgendeinem anderen DB-System
arbeiten.

> Wird denn VB6 von Microsoft weiter unterstützt - wie lange noch?

Ich habe hier noch einige uralte Programme, die ich noch mit QuickBasic
unter MS-DOS 3.x geschrieben habe. Die laufen auch unter XP noch ohne
Probleme in der DOS-Box. Ich wüsste erst mal keinen Grund, warum es bei
VB-Programmen grundsätzlich anders ablaufen sollte.

> Was ist bei neuen Betriebssystemen, wie sicher kann man sein, eine heute
> unter VB6 geschriebene Anwendung auch in 5, 10 oder mehr Jahren unter
> dann aktuellen Betriebssystem und Hardware nutzen zu können (von 117
> Jahren will ich gar nicht reden).

Da kannst Du ebensowenig sicher sein, wie bei jeder anderen
Programmiersprache. Wenn es Microsoft oder irgendeinem anderen Anbieter
einfällt nur noch ein zum derzeitigen Windowsstandard nicht mehr kompatibles
System zu liefern, dann laufen bisherige Windows-Programme eben auf diesem
System nicht mehr. Ein VBclassic-Programm setzt auf das Windows-APi auf. Ein
VB.net Programm tut das im Endeffekt genauso.
Bei VBclassic ist zwischen Programm und APi die VB-Laufzeitdatei, bei VB.net
ist zwischen Programm und APi das Net-Framework. Beides sind
Laufzeitdateien, die halt unterschiedliche Namen haben.

Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tips u. Beispielprogrammen)