SQL-Fehler CPF427F nach Systemwechsel

[lossin]

Hallo Ihr Beiden,

ich störe Euren Dialog ja nur ungerne :-)
aber ich spiele jetzt erstmal die aktuellsten PTFs ein und
hoffe auf das Wunder !
Wir haben übrigens zur Zeit noch V5R3.

Ansonsten hoffe ich, daß die Schlafmützen bei IBM es endlich packen unser System zu aktivieren, damit ich einen Call aufmachen
kann.

mfg
H.Lossin

[BenderD]

Hallo,

die sogenannte SQE, von der so mancher schwärmt, wird seit längerer Zeit implementiert; mit jedem Release und mit jedem Database Group PTF kommt da ein Stück neu auf die Büchse, oft mit massiven Problemen für Database Server Betrieb und ähnliches SQL Umfeld. Was habt ihr denn für einen Group PTF Stand (WRKPTFGRP ?) für die Datenbank? Wenn der Blank ist, dann ist eure Maschine schlampig installiert und ich würde den Lieferanten an den Ohren ziehen und zu Ostern ein Schleifchen von selbigen binden, allerdings habt ihr dann Hoffnung, dass es funzt, es gibt da durchaus saubere Stände.

mfg

Dieter Bender

PS: mit V5R4 würde ich warten empfehlen - und Vorsicht bei Group PTFs Database - never run a changing System.

Hallo Ihr Beiden,

ich störe Euren Dialog ja nur ungerne :-)
aber ich spiele jetzt erstmal die aktuellsten PTFs ein und
hoffe auf das Wunder !
Wir haben übrigens zur Zeit noch V5R3.

Ansonsten hoffe ich, daß die Schlafmützen bei IBM es endlich packen unser System zu aktivieren, damit ich einen Call aufmachen
kann.

mfg
H.Lossin

[Fuerchau]

Bezüglich dieser SQE darfst du leider nicht auf Wunder hoffen.

Bei Einführung V5R3 musste ich meine ODBC-Timeouts im Client auf teilweise 30.000 Sekunden stellen, obwohl die spätere tatsächlich Antwortzeit nur ca. 3 Sekunden betrug.
Eben wegen der SQL0666-Fehlermeldung !
Eine Einstellung seitens der AS/400 gibt es da wirklich nicht.

[BenderD]

@Baldur: für schwarz sehen bin ich zuständig
so Hoffnungslos ist das auch wieder nicht, ich kenne da eine Büchse mit V5R3, reinrassiger SQL Datenbank (ohne jede DDS erstellte logische), die massig generierte SQLs gegen diese Datenbank mit Terrabyte von Daten über ODBC loslässt und das läuft unter einem real existierenden Group PTF Stand stabil ohne jede CPF427F; den Group PTF Stand, den ändern wir allerdings nur in allergrößter Not und V5R4 kann warten.

Bezüglich dieser SQE darfst du leider nicht auf Wunder hoffen.

Bei Einführung V5R3 musste ich meine ODBC-Timeouts im Client auf teilweise 30.000 Sekunden stellen, obwohl die spätere tatsächlich Antwortzeit nur ca. 3 Sekunden betrug.
Eben wegen der SQL0666-Fehlermeldung !
Eine Einstellung seitens der AS/400 gibt es da wirklich nicht.

[Sven Schneider]

Wenn es wirklich über den iSeries Access ODBC-Treiber läuft, gibt es im ODBC-TreiberManager unter "Leistung" und Button "Erweitert" die Möglichkeit ein Häkchen zu deaktivieren.

Abfragezeitlimit zulassen

Hiermit kann die Anwendung das Attribut für das Abfragezeitlimit festlegen.
Bei Inaktivierung dieses Kontrollkästchens wird die Unterstützung des Attributs für das Abfragezeitlimit inaktiviert.
SQL-Abfragen sind dann solange aktiv, bis sie vollständig ausgeführt worden sind

Die entsprechende DSN property heisst :
QueryTimeout=0

siehe auch hier :
IBM - ODBC Query Timeout Property: SQL0666 Estimated Query Processing Time Exceeds Limit

So wie es aussieht gehen deine Abfrage aber über die Jet-Engine bzw. DAO.
Die zugehörigen properties - ConnectionTimeout (default=600) und QueryTimeout(default=60) - findest du in der Windows-Registrierung (Regedit.exe) unter :

HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\3.5(oder 4.0)\Engines\ODBC

[Fuerchau]

Diese Einstellungen gelten allerdings für jeden ODBC-Treiber.
Auch DAO erlaubt das Setzen des QueryTimeout im Query/Worspace-Objekt, so dass die Defaults individuell angepasst werden.

MS-Access übernimmt diesen Default übrigens in seine verknüpften Tabellen, und Passthru-Abfragen.
Eine nachträgliche Änderung in der Registry hat dann keinen Erfolg.
Auch hier muss man dann die Eigenschaften des jeweiligen Objektes bemühen und den ODBC-Timeout ggf. anpassen.

[Sven Schneider]

@Fuerchau:
ich hatte ja geschrieben das es die default-Einstellungen sind und diese gelten nur für Zugriffe über die jet.engine.
Wenn man die Werte in der Registrierung ändert, betrifft das alle Zugriffe dieses PC's über die jet.engine bzw. DAO.
Bei DAO (ab 3.5) auch nur dann, wenn der Zugriff über die jet.engine erfolgt und nicht über ODBCDirect - hier gelten wieder die Einstellungen des jeweiligen ODBC-Treibers.

Bei ADO gibt es wieder andere default-Werte :
CommandTimeout=30
ConnectionTimeout=15

Zu Access :
das Property QueryTimeout lässt sich bei eingebundenen Tabellen nur über die Eigenschaften einer dazugehörigen Abfrage ändern. (ODBC-Wartezeit, entspricht DAO Eigenschaft ODBCTimeout)

Das trifft auch auf ältere Versionen von MS-SQL (bis 6.5) in Verbindung mit externen Tabellen zu, da hier ebenfalls die jet engine bzw. DAO benutzt wurde.
Auch hier kann man die timeouts einstellen.

Der Property ConnectionTimeout (default=600) kann für die Jet.engine ! nur in der Registrierung geändert werden. Im Gegensatz zu Property QueryTimeout (bzw ODBCTimeout).

siehe auch hier :
Codekabinett - mySQL*&*Access