Subject | Re: Update numeric problem |
---|---|
Author | timothysshea |
Post date | 2010-08-23T12:55:08Z |
Thank you for your reply.
The trouble is that the problem occurs occasionally and took a while to reproduce here.
As mentioned, I am using Win32 Firebird 2.1.3, Superserver via the ODBC driver build 2.00.00.148, but happened with Firebird 2.0 as well. The field in question is Numeric(15,1).
The language is Visual Objects which in this case is merely using the Windows ODBC API to pass the statement as a string. There are very many statements in the app, up to the complexity of the merge statement. All operate without a fuss. Just do a commit after the statement.
Several users were complaining about the update statement not working and I thought it must have been something else. Managed to reproduce it on an XP machine after several goes. Reproduced it using Flamerobin as well.
Others must have run into the same problem and I am hoping they may be able to shed some light from their experience.
My previous experience with intermittent problems like this has been an initialised string not long enough to contain the null termination character. If the next character in memory is a null, then no problem. If not, then false results.
Hoping it is not a bug, but a configuration issue.
Tim
The trouble is that the problem occurs occasionally and took a while to reproduce here.
As mentioned, I am using Win32 Firebird 2.1.3, Superserver via the ODBC driver build 2.00.00.148, but happened with Firebird 2.0 as well. The field in question is Numeric(15,1).
The language is Visual Objects which in this case is merely using the Windows ODBC API to pass the statement as a string. There are very many statements in the app, up to the complexity of the merge statement. All operate without a fuss. Just do a commit after the statement.
Several users were complaining about the update statement not working and I thought it must have been something else. Managed to reproduce it on an XP machine after several goes. Reproduced it using Flamerobin as well.
Others must have run into the same problem and I am hoping they may be able to shed some light from their experience.
My previous experience with intermittent problems like this has been an initialised string not long enough to contain the null termination character. If the next character in memory is a null, then no problem. If not, then false results.
Hoping it is not a bug, but a configuration issue.
Tim
--- In firebird-support@yahoogroups.com, Svein Erling Tysvær <svein.erling.tysvaer@...> wrote:
>
> If
>
> update mytable set total=total+10.12 where mykey=10
>
> doesn't do what it is supposed to do, then there's a serious problem with Firebird. I haven't heard of such a problem before, and wonder if you may have simplified your problem too much? If it was two statements running in separate transactions - like
>
> SELECT total FROM MyTable
> UPDATE MyTable SET total = :total + 10.12
>
> then it would be easy to understand, but within one statement, it simply doesn't sound right.
>
> So please tell us more, which transaction isolation do you use, which version of Firebird, any programming language etc. Have you observed the problem by simply running your update statement using isql, FlameRobin or similar?
>
> Set
>
> -----Original Message-----
> From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of timothysshea
> Sent: 23. august 2010 10:04
> To: firebird-support@yahoogroups.com
> Subject: [firebird-support] Update numeric problem
>
> I am having a problem where the following :
>
> update mytable set total=total+10.12 where mykey=10
>
> Simply doesn't work; occasionally. The numeric field is not null and no error is reported. The numeric field (total) is not updated.
>
> The command
>
> update mytable set total=22.2 where mykey=10
>
> always works.
> Likewise
>
> update mytable set total=total+10.12, databasename='Firebird' where mykey=10
>
> always updates databasename to 'Firebird', but sometimes does not update total.
>
> Seems to happen on Terminal Servers more than other systems.
> Using Win32 Firebird 2.1.3, Superserver via the ODBC driver build 2.00.00.148, but happened with Firebird 2.0 as well.
>
> This seems like a pretty basic problem and only happens occasionally. Otherwise, Firebird appears to be virtually bulletproof.
>
> Any ideas?
>
> Thanks in advance.
> Tim
>