🚀 go-pugleaf

Hi,
after trying and despairing a lot of hours I found out the problem. The
problem was not the precision of numbers or something else. The problem was
that several fields of the Access Database had set up a standard value and
after an insert the field becomes the standard value if the field is empty.
If you didn�t refresh the table and try to update such row the provider
tries to find the row with the fields you gave a pfinwhere. And now the
provider didn�t find the row because some fields had become values. I never
had thought of something like this because I always set up my own Databases
and never used standard values. But this time I got a Database to work with.
Argghh this is very annoying

But now it works thanks!


> >I didn�t find out why I get this error but I found out that it must be
> >something with the structure of the table. When I delete some fields out
of
> >the table it sometimes works. It is a little bit difficult to find out
what
> >fields because that table contains about 40 fields. I tried around but it
is
> >impossible.
>
> This type of error commonly occurs if you have and double precision
> numbers,  or floating point numbers,  or any data type which is stored as
> one of those two.  One way to resolve this error is usually to change the
> UpdateMode of the object from upWhereAll to either upWhereKey or
> upWhereChanged.  This way the floating point value will only be compared
> when it is a key field or when it is a field that is changed.  If this is
> the cause of the error,  the only other solution I am aware of is to use a
> database/driver which implements IEEE Floating point rounding the same in
> the DB and in the driver.  For some reason the MS ODBC drivers for SQL
> Server and MS Access do not seem to fit this category though...
>
> Jerry Bloomfield (TeamB)
> --
> http://www.teamb.com                                      JersWork@iwc.net
> Please do *NOT* send private e-mail without prior permission (my anti-spam
> filters will probably just delete it anyway <g>)