none
VB6 Anwendung auf Netzwerklaufwerk bleibt bei Zugriff auf SQL Server 6.5 stehen RRS feed

  • 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

    Donnerstag, 12. August 2010 19:51

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)

    Donnerstag, 2. September 2010 16:11

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

    Donnerstag, 2. September 2010 11:41
  • 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)

    Donnerstag, 2. September 2010 16:11