From: | "Henshall, Stuart - WCP" <SHenshall(at)westcountrypublications(dot)co(dot)uk> |
---|---|
To: | "'Michael Calabrese'" <m2calabr(at)yahoo(dot)com>, pgsql-odbc(at)postgresql(dot)org |
Subject: | RE: Float Percision with MS Access 97 |
Date: | 2001-08-21 08:06:27 |
Message-ID: | E2870D8CE1CCD311BAF50008C71EDE8E01F74681@MAIL_EXCHANGE |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-odbc |
I use Row Versioning to get around this (my thanks to who ever put that in).
You'll need to re-link as it adds in the xmin field. Access will then use
the Primary Key and xmin in its where clause to identify the row.
Hope this helps,
- Stuart
> -----Original Message-----
> From: Michael Calabrese [SMTP:m2calabr(at)yahoo(dot)com]
> Sent: Monday, August 20, 2001 11:03 PM
> To: pgsql-odbc(at)postgresql(dot)org
> Subject: Re: Float Percision with MS Access 97
>
> I am sorry, but I guess I did not make my question
> clear. I am not looking for greater backend precision
> (ie moving to float8). There seems to be a
> mis-comunication between Access and postgres with
> float4.
> Access is seeing the number with fewer digits than
> want must be in postgres. If I do a :
> UPDATE Parts SET Count = round(Count,4);
> Then the access query from my first email will work.
> This is a pain right now because my users will get a
> write conflict error, call me, I will find the
> offending field, do and Update with the round(x,4),
> then it will work.
>
> I could fix it by putting round(x,4) with all float
> fields, but this seems like a poor fix.
>
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2001-08-21 08:51:19 | Re: New CVS doesn't compile |
Previous Message | Hiroshi Inoue | 2001-08-21 02:05:37 | Re: New CVS doesn't compile |