Benutzer mit den meisten Antworten
VB6 Anwendung auf Netzwerklaufwerk bleibt bei Zugriff auf SQL Server 6.5 stehen

Frage
-
Hallo Leute,
reines Interesse:
ich SW Entwickler mit langjähriger Erfahrung muss zwecks Wartung einer App aus dem Jahre 2001 auf einen SQL Server 6.5 mittels VB6 u DAO 3.6 zugreifen.
Der involvierte PC läuft unter XP SP3.
Start der App aus der IDE funktioniert klaglos. Ich compiliere die App, starte die App auf einem *lokalen* LW - alles passt. Ich starte das .Exe auf einem verbundenen Netzlaufwerk u die App bleibt nach einiger Zeit ( Verbindungsversuche ? =) stehen, dann hängt der gesamte Rechner. Nicht, dass mir das schlaflose Nächte bereitet, aber interessieren würde es mich schon, ob irgendjemand wenigstens eine Idee hat woran das liegen könnte.
Die App baut nat. sofort in den Init Prozeduren eine Verbindung zum SQL Server auf, um diverse Werte aus Systemtabellen abzufragen.
Die SQL Server Verbindung läuft über eine System DSN, die einwandfrei funktioniert.
Vlt. fällt ja jemand etwas ein ?
lg
Andi
Antworten
-
Hallo Andreas,
reines Interesse:
ich SW Entwickler mit langjähriger Erfahrung muss zwecks Wartung
einer App aus dem Jahre 2001 auf einen SQL Server 6.5 mittels VB6
u DAO 3.6 zugreifen.
Der involvierte PC läuft unter XP SP3.
Start der App aus der IDE funktioniert klaglos. Ich compiliere die
App, starte die App auf einem lokalen LW - alles passt.Da es sich dabei offenbar um Deinen Entwicklungsrechner
handelt sind neben der *.exe auch alle für den Ablauf dieser
.exe sonstigen Laufzeitdateien (.ocx, *.dll) vorhanden und
soweit nötig registriert.Ich starte das .Exe auf einem verbundenen Netzlaufwerk u die
App bleibt nach einiger Zeit ( Verbindungsversuche ? =) stehen,
dann hängt der gesamte Rechner. Nicht, dass mir das schlaflose
Nächte bereitet, aber interessieren würde es mich schon, ob
irgendjemand wenigstens eine Idee hat woran das liegen könnte.#Auch hier müssen (lokal) auf dem "ausführenden" Rechner alle notwendigen
Laufzeitdateien vorhanden sein auch wenn die *.exe sich auf einem
entfernten Rechner irgendwo im LAN befindet.
Die App baut nat. sofort in den Init Prozeduren eine Verbindung zum
SQL Server auf, um diverse Werte aus Systemtabellen abzufragen.Und dazu sind die entspr. Laufzeitdateien erforderlich.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)- Als Antwort markiert Robert BreitenhoferModerator Mittwoch, 6. Oktober 2010 11:06
Alle Antworten
-
Hi Andreas,
Netzlaufwerke sind sehr anfällig. Vor allem, wenn etwas im Netz los ist.
Am besten bist du bedient, wenn du eine Art ConnectionPrüfen einbaust, also so etwas in der Art von, wenn ein Error da ist, dann baue eine neue Verbindung auf.
(Nur ein Beispiel)
If con.Errors.Count > 0 Then conTemp.ConnectionString = con.ConnectionString conTemp.CommandTimeout = con.CommandTimeout conTemp.ConnectionTimeout = con.ConnectionTimeout Set con = Nothing Set con = conTemp con.Open End If
mfg
-
Hallo Andreas,
reines Interesse:
ich SW Entwickler mit langjähriger Erfahrung muss zwecks Wartung
einer App aus dem Jahre 2001 auf einen SQL Server 6.5 mittels VB6
u DAO 3.6 zugreifen.
Der involvierte PC läuft unter XP SP3.
Start der App aus der IDE funktioniert klaglos. Ich compiliere die
App, starte die App auf einem lokalen LW - alles passt.Da es sich dabei offenbar um Deinen Entwicklungsrechner
handelt sind neben der *.exe auch alle für den Ablauf dieser
.exe sonstigen Laufzeitdateien (.ocx, *.dll) vorhanden und
soweit nötig registriert.Ich starte das .Exe auf einem verbundenen Netzlaufwerk u die
App bleibt nach einiger Zeit ( Verbindungsversuche ? =) stehen,
dann hängt der gesamte Rechner. Nicht, dass mir das schlaflose
Nächte bereitet, aber interessieren würde es mich schon, ob
irgendjemand wenigstens eine Idee hat woran das liegen könnte.#Auch hier müssen (lokal) auf dem "ausführenden" Rechner alle notwendigen
Laufzeitdateien vorhanden sein auch wenn die *.exe sich auf einem
entfernten Rechner irgendwo im LAN befindet.
Die App baut nat. sofort in den Init Prozeduren eine Verbindung zum
SQL Server auf, um diverse Werte aus Systemtabellen abzufragen.Und dazu sind die entspr. Laufzeitdateien erforderlich.
Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)- Als Antwort markiert Robert BreitenhoferModerator Mittwoch, 6. Oktober 2010 11:06