Moin!

Wir haben Probleme, Timestamp-Felder auf "Null" zu setzen, wir verwenden
dafür PDO unter Visual Basic 6.

Der folgende Code erzeugt die Meldung:
"FEHLER: Datum/Zeit-Feldwert ist außerhalb des gültigen Bereichs:
>>0000-00-65535 65535:00:00.000000016<<"

-----------------------------
strSql =3D "Select * From auftrag Where nummer In('0131') Order By nummer=
"

Set ds1 =3D objHMVBDV.ADOConnection.OpenRecordset(strSql, adOpenDynamic,
adLockOptimistic)
ds1.Fields("erloeseaufgebautam") =3D Null
ds1.Update
Set ds1 =3D Nothing

-----------------------------
Wenn wir das betreffende Feld per SQL-Statement auf "Null" setzen,
funktioniert es, es funktioniert auch, wenn wir statt 8.2.1 oder 8.2.0
eine vorherige Version (z.B. 8.0.x) verwenden.

Der Server läuft unter Linux (Postgres 8.2.0), die Clients laufen unter
Windows XP.

Dies dürfte ein Bug sein, oder? Gibt es irgendwelche Möglichkeiten, d=
as zu
umgehen? Wir können leider die Felder nicht SQL-Statement setzen, der
Aufwand wäre zu hoch. (Wir entwickeln hauptsächlich unter Sybase und =
haben
einige (wenige) Kunden unter Postgres) Die Anzahl der zu ändernden Stel=
len
im Programm ist unabsehbar.

Eine Lösung im ODBC-Treiber wäre ideal.

Tschau!

Michael
--
"The Macintosh may only have 10% of the market,
but it is clearly the top 10%" - Douglas Adams 1952-2001


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

am Fri, dem 19.01.2007, um 10:45:00 +0100 mailte Michael Vogel folgendes=
:
> Moin!
>
> Wir haben Probleme, Timestamp-Felder auf "Null" zu setzen, wir verwende=
n
> dafür PDO unter Visual Basic 6.
>
> Der folgende Code erzeugt die Meldung:
> "FEHLER: Datum/Zeit-Feldwert ist außerhalb des gültigen Bereichs:
> >>0000-00-65535 65535:00:00.000000016<<"
>
> -----------------------------
> strSql =3D "Select * From auftrag Where nummer In('0131') Order By numm=
er"
>
> Set ds1 =3D objHMVBDV.ADOConnection.OpenRecordset(strSql, adOpenDynamic=
,
> adLockOptimistic)
> ds1.Fields("erloeseaufgebautam") =3D Null
> ds1.Update
> Set ds1 =3D Nothing
>
> -----------------------------
> Wenn wir das betreffende Feld per SQL-Statement auf "Null" setzen,
> funktioniert es, es funktioniert auch, wenn wir statt 8.2.1 oder 8.2.0
> eine vorherige Version (z.B. 8.0.x) verwenden.
>
> Der Server läuft unter Linux (Postgres 8.2.0), die Clients laufen unt=
er
> Windows XP.
>
> Dies dürfte ein Bug sein, oder? Gibt es irgendwelche Möglichkeiten,=
das zu
> umgehen? Wir können leider die Felder nicht SQL-Statement setzen, der

Man könnte einen before-trigger nehmen, der aus dem übergebenen Schro=
tt
ein NULL macht. Ja, das ist keine Fehlerbehebung...

Wobei ich mir grad nicht sicher bin, ob das in einem Trigger nicht schon
zu spät ist, also ob die prüfung durch PG nicht schon vorher nörgel=
t.
Ein direktes SQL zu schicken wäre natürlich schöner.


Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Ich erlaub mir mal, wieder in die Liste zu antworten.


am Fri, dem 19.01.2007, um 12:24:29 +0100 mailte Michael Vogel folgendes=
:
>
> A. Kretschmer schrieb:
> > Man könnte einen before-trigger nehmen, der aus dem übergebenen S=
chrott
> > ein NULL macht. Ja, das ist keine Fehlerbehebung...
>
> Selbst wenn, dann müsste der Trigger doch bestimmt pro Tabelle gebaut
> werden, oder? Unsere Applikation hat um die 200 Tabellen.

Jepp.


> Gibt es irgendwelche zu erwartenden Probleme, wenn der Kunde - bis zu
> einer Behebung des Problems - mit dem Client auf 8.0.x arbeitet, der
> Server aber auf 8.2.0 bleibt?

Unwahrscheinlich. Aber Du solltest das auch den Machern des
JDBC-Treibers um die Ohren hauen^W^W^W^W bugreporten, damit das gefixt
wird.


Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Moin!

A. Kretschmer schrieb:
> Ich erlaub mir mal, wieder in die Liste zu antworten.

Ups, sorry. Ich hatte nicht darauf geachtet, dass hier kein List-Reply
gesetzt ist.

> am Fri, dem 19.01.2007, um 12:24:29 +0100 mailte Michael Vogel folgende=
s:
>>
>> A. Kretschmer schrieb:
>> > Man könnte einen before-trigger nehmen, der aus dem übergebenen
>> Schrott
>> > ein NULL macht. Ja, das ist keine Fehlerbehebung...
>>
>> Selbst wenn, dann müsste der Trigger doch bestimmt pro Tabelle gebau=
t
>> werden, oder? Unsere Applikation hat um die 200 Tabellen.
>
> Jepp.

Hmm, okay. Vergessen wir das mal ;-)

>> Gibt es irgendwelche zu erwartenden Probleme, wenn der Kunde - bis zu
>> einer Behebung des Problems - mit dem Client auf 8.0.x arbeitet, der
>> Server aber auf 8.2.0 bleibt?
>
> Unwahrscheinlich. Aber Du solltest das auch den Machern des
> JDBC-Treibers um die Ohren hauen^W^W^W^W bugreporten, damit das gefixt
> wird.

Einen Bugreport habe ich bereits geschrieben, nahezu wortwörtlich wie
meine Anfrage hier in der Liste - nur auf Englisch natürlich.

Schauen wir mal, wie schnell da was kommt.

Michael
--
"The Macintosh may only have 10% of the market,
but it is clearly the top 10%" - Douglas Adams 1952-2001


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend