Fehler an Adresse 40558158 in gds32.dll

[Günter Forster]

Hallo,

ist jemanden dieser Fehler bekannt. Er erscheint bei zugriff über ISDN auf den Server. Bisher ging alles gut. In einem Update für das Programm habe ich regelmäßig ein commit und ein Starttransaction drin. Kann das ein Timingproblem sein ? Lokal läuft alles einwandfrei.

Gruß Günter

[Andreas Kosch]

Hallo,

der InterBase ist nahezu berüchtigt für seine Probleme, die er mit direkten Datenbank-Sessions über ISDN-Router hat. Leider sind diese Effekte nur schwer reproduzierbar.

Generell ist beim WAN-Zugriff die Three-tier-Architektur der klassischen C/S-Architektur überlegen, denn bei Three-tier ruft der Client nur das eigene Programm-Modul auf dem Server auf, wobei dieser lokal über das LAN auf den InterBase zugreifen kann. In dieser Konfiguration spielt das ISDN-Problem keine Rolle mehr (denn hier kümmert sich Windows um die Details)

[Günter Forster]

Hallo Herr Kosch,

der ISDN - Anschluß hat bisher einwandfrei funktioniert. Ich habe das Programm komplett neu geschrieben. Der Fehler tritt jetzt auf, wenn diverse Storedprocs aufgerufen werden. Ab dem dritten Aufruf entsteht obiger Fehler.
Ist es möglich, das ab IBX 5.02 für jede Stored-Proc eine eigene Transaction gestartet werden muß ?<>
Das war bisher jedenfalls nicht nötig gewesen !

Gruß Forste

[Thomas Steinmaurer]

Hallo Günter,<br><br>
in Verbindung mit Stored Procedures, die im Client mehrfach hintereinander (z.B. in einer Schleife) aufgerufen werden, existiert ein bereits bekannter (alter) Bug in Interbase.<br><br>
Versuch mal ein explizites <b>Unprepare</b> bevor die Stored Procedure Prepared oder ausgeführt wird.<br><br>
Ein weiterer Punkt ist, dass sichergestellt sein soll, dass immer nur eine Version von gds32.dll im Windows-Suchpfad vorkommt.<br><br>
Handelt es sich um eine Multithread-Anwendung, dann benötigt jeder Thread eine eigene Connection unter Verwendung eines Remote-Verbindungspfades (auch für lokale Verbindungen!)<br><br>

Thoma

[Günter Forster]

Hallo,

Ich habe es fast fertigbekommen. Mit prepare und unprepare kann ich alles nutzen. Nur an einer Stelle hängt es : Ich habe eine Blatt mit dem Auftrag des Kunden und am oberen Rand Knöpfe, um in verschiedenen Geschwindigkeiten zu blättern. Beim anklicken wird zur erst eine Storedproc aufgerufen, die 'max' und 'min' der Auftragnummern zurüchgibt. Genau diese Funktion <pre>
create procedure grenzen
returns
(start integer
ende integer)
as
select min(aufnummer), max(aufnummer) from Auftrag
into :Start, :Ende;

</pre>
kann nur einmal aufgerufen werden, trotz prepare und unprepare. Es funktioniert nur, wenn ich die Transaction deaktiviere und wieder starte. Dabei werden leider die lookuptabellen auch geschlossen. Das dauert dann dem Kunden zu lang.<br>

Gibt es einen Bug bei der verwendung von Grundfunktionen in den Stored Procedures ? Dauernd ein commit abschicken, auch wenn nichts passiert kann es ja nicht sein, oder ?

Gruß Günte

[Thomas Steinmaurer]

Hallo Günter,<br><br>
da diese Stored Procedure eine Ergebnismenge zurückliefert und nicht zum Beispiel ein DELETE od. INSERT durchführt, ist es wichtig am Schluß der Stored Procedure ein SUSPEND einzubauen. Ein SUSPEND stellt sicher, dass die RETURN-Werte auch tatsächlich zurückgegeben werden. Deine Stored Procedure sollte also in etwa so aussehen:<br><br>
CREATE PROCEDURE GRENZEN RETURNS (START INTEGER, ENDE INTEGER)<br>
AS<br>
SELECT MIN(AUFNUMMER), MAX(AUFNUMMER) FROM AUFTRAG INTO :START, :ENDE;<br>
SUSPEND;<br>
END<br><br>
Noch ein Hinweis: Um das MIN, MAX bei einer grossen Auftragstabelle zu beschleunigen, würde ich noch einen aufsteigenden(ASC; sofern dies nicht der Primärschlüssel ist) und absteigenden(DESC) Index auf AUFNUMMER definieren. MIN verwendet den aufsteigenden Index und MAX den absteigenden Index. Somit kann man auch bei einer grossen Tabelle rasch zu einem Ergebnis kommen.<br><br>
Thomas Steinmaurer<br>
http://www.iblogmanager.co