[VB6] Datenbank-Probleme
Lothar Geyer
ich jetzt hier richtig mit meinen Fragen?
Ich versuchs halt mal.
Bei einem Kunden läuft SQLServer Express. Und wenn man dort meine
Anwendung länger laufen lässt, ohne was zu tun (also z.B. während der
Mittagspause), meldet sie nach einiger Zeit (genau kann ich das noch
nicht sagen) folgenden Fehler:
[DBNETLIB][ConnectionRead (recv()).]Allgemeiner Netzwerkfehler. Weitere
Informationen finden Sie in der Dokume
Time='30.09.10 17:34:40' App='TelMarkt:2.2.2' ADO-version='2.8'
Computer='USER6'
Method: colAlarme.refreshRSA
Number: -2147467259 = &H80004005 = vbObjectError - 245755 =
ERRMAP_APP_FIRST - 250953
Source: Microsoft OLE DB Provider for SQL Server
In der Methode colAlarme.refreshRSA wird lediglich ein Select abgesetzt.
Und das passiert mittels Timer alle 60 Sekunden.
Da diese Meldung nur bei einem einzigen Kunden auftritt, ich aber nichts
Verdächtiges bei der Installation finden kann: wo sollte ich nach der
Ursache suchen? An der Anwendung kann es schlecht liegen. Gibt es da
irgendwelche Parameter, die auf dem Server zu ändern wären?
Lothar Geyer
Wolfgang Enzinger
>[...] bin ich jetzt hier richtig mit meinen Fragen?
In dem Fall wohl nicht, da das Problem IMHO weder mit Datenbanken noch mit VB6
zu tun hat, s.u..
>[DBNETLIB][ConnectionRead (recv()).]Allgemeiner Netzwerkfehler. Weitere
^^^^^^^^^^^^^^^^^^^^^^^^^^
Das ist doch schon recht aussagekräftig, nicht?
>In der Methode colAlarme.refreshRSA wird lediglich ein Select abgesetzt.
>Und das passiert mittels Timer alle 60 Sekunden.
D.h. in gewisser Weise testet deine Anwendung nebenbei auch die
Zuverlässigkeit des Servers resp. des Netzwerks.
Ich hatte sowas mit einer meiner Anwendungen schon mehrfach, die zwar nicht so
schön regelmässig, dafür dann bei Bedarf recht grosse Datenmengen von einem
Fileserver abruft. Angeblich gab es nur mit meiner App Probleme. Das stimmte
evtl. sogar, aber es lag immer letztlich immer an einem Netzwerk-Defekt. Auch
ein Hauptspeicher-Defekt am Fileserver hat sich so schon zweimal manifestiert.
"Aber wir öffnen unsere Word-Dokumente doch auch von diesem Server, ohne
Probleme!1!!!". Das mag ja sein, aber das macht man eben nicht so häufig bzw.
die Dateien sind in aller Regel nicht so sonderlich gross.
>An der Anwendung kann es schlecht liegen.
Falsch, es liegt *immer* an deiner Anwendung! ;-)
Ernsthaft: Je intensiver eine Anwendung mit einem Server redet, umso grösser
die Wahrscheinlichkeit, dass sie die Arschkarte zieht und als erstes mit
unzuverlässiger Hardware ein Problem bekommt. Natürlich ist sie dann erst mal
schuld.
Ich kann dir natürlich nicht garantieren, dass das in deinem Fall so zutrifft,
aber anhand der Indizien würde ich es auf alle Fälle in Betracht ziehen.
--
Viele Grüsse,
Wolfgang
http://www.enzinger.net
Peter Fleischer
> ...
>>[DBNETLIB][ConnectionRead (recv()).]Allgemeiner Netzwerkfehler. Weitere
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Das ist doch schon recht aussagekräftig, nicht?
Hi Wolfgang,
ich hatte leider schon falsche Programmabläufe, die unter bestimmten Umgebungen zu Fehlern mit Fehlercode &H80004005 führten. Dieser Fehlercode ist der "Mülleimer" für alle möglichen Fehler und die Fehlerausschrift ist nicht unbedingt aussagekräftig. Neben den Netzwerkinstabilitäten sollte auch der eigene Programmcode überprüft werden. Dazu kann man beispielsweise die Datenzugriffsklasse durch asynchrone parallele Zugriffe so stressen, dass möglichst häufig das Connection-Objekt seinen Zustand (Open/Close) ändert. Zusätzlich kann man die CPU des Datenbankservers intensiv belasten, so dass es Zeitverzögerungen bei der Arbeit der Datenzugriffsklasse gibt.
--
Viele Gruesse
Peter
Lothar Geyer
Am 01.10.2010 04:46, schrieb Peter Fleischer:
> ...
> ich hatte leider schon falsche Programmabläufe, die unter bestimmten
> Umgebungen zu Fehlern mit Fehlercode &H80004005 führten. Dieser
> Fehlercode ist der "Mülleimer" für alle möglichen Fehler und die
> Fehlerausschrift ist nicht unbedingt aussagekräftig. Neben den
> Netzwerkinstabilitäten sollte auch der eigene Programmcode überprüft
> werden. Dazu kann man beispielsweise die Datenzugriffsklasse durch
> asynchrone parallele Zugriffe so stressen, dass möglichst häufig das
> Connection-Objekt seinen Zustand (Open/Close) ändert. Zusätzlich kann
> man die CPU des Datenbankservers intensiv belasten, so dass es
> Zeitverzögerungen bei der Arbeit der Datenzugriffsklasse gibt.
Also das Programm läuft auf einigen 100en von PCs - ohne diesen Fehler.
(Es kommen zwar ab und zu Netzwerkfehler vor, aber da waren die Ursachen
bekannt.) Und in diesem Netzwerk laufen knapp 20 PCs mit dieser
Anwendung. Und nur auf einem wird dieser Fehler gemeldet. So dass
Wolfgang (hoffe ich auch) schon richtig liegen könnte. Auf jeden Fall
habe ich jetzt mal eine Richtung, in die ich weiter testen / beobachten
kann.
Lothar Geyer
Lothar Geyer
ich habe gerade erfahren, dass der Rechner, auf dem das Problem
auftritt, in den StandBy-Modus geschickt wird. Könnte das die Ursache sein?
Und als Vorgriff:
Gibt es die Möglichkeit, den StandBy von der Anwendung her zu verhindern
oder auch ihn aufzuheben, falls er aktiv ist? Oder ihn abzufragen? Dann
könnte man zumindest zumindest entsprechend reagieren.
Lothar Geyer
Stefan Scholl
Lothar Geyer
> Bitte de.comp.lang.vbclassic benutzen.
>
Huch! Die ist schon aktiv? Das darf doch nicht wahr sein.
Ich freu mich riesig!!!
Aber: kann man diesen Thread komplett dorthin umziehen lassen?
Lothar Geyer
Lothar Geyer
mache, wenn ich schon gepostet habe ;-( ):
Wenn der Rechner in den Suspend-Mode versetzt wird, was passiert dann
eigentlich? Dann wird doch der Hauptspeicher gesichert und die CPU
schlafen geschickt, oder?
Falls ja: Was passiert z.B. mit aktiven Timern? Was passiert, wenn der
Rechner durch einen externen Event (Telefon-Anruf) geweckt wird?
Lothar Geyer
Ingo Moch
Stefan Scholl wrote:
> Bitte de.comp.lang.vbclassic benutzen.
Dazu war er rund eine Stunde zu frueh:
<ftp://ftp.fu-berlin.de/doc/usenet/control/de/de.comp.lang.vbclassic.gz>
----------------------------------------------------------------
Newsgroups: de.admin.news.announce,de.comp.lang.vbclassic
Subject: cmsg newgroup de.comp.lang.vbclassic
Control: newgroup de.comp.lang.vbclassic
Message-ID: <newgroup-de.comp.lang...@dana.de>
Date: Thu, 30 Sep 2010 19:20:23 +0200
----------------------------------------------------------------
</>