Hi Luciano, Not that this reply will solve your problem, but let it serve as a notice. It is NEVER a good idea to use a FLOAT/BLOB column in your where clause as MySQL can not uniquely identify the record. Especially not with floats because of the inherent floating point error made between machines after a specific number of decimals (which depends on the hardware on which the MySQL is running). To clarify:
select MyFloat from MyTable; Machine A might result in: 0.123456789012345[987345765] Machine B, using exactly the same MySQL version with exactly the same table and data: 0.123456789012345[765365423] Because of precision floating point errors (in the sample, after the 15th decimal) the values in the square brackets will differ and effectively be random numbers. You can thus see the problem in asking MySQL to match floating point data using a WHERE clause. In fact you can do the same query twice on the same machine and MySQL won't be able to locate the record as the ultimate float value will differ twice in a row. Always remember computers are binary machines which loves integers. After filling the internal 8 bytes with a floating value, the rest of any floating value precision becomes a toss up. Another sample (MySQL 4.1.7): mysql> select pi(); +----------+ | PI() | +----------+ | 3.141593 | +----------+ 1 row in set (0.00 sec) mysql> select pi()=3.141593; +---------------+ | pi()=3.141593 | +---------------+ | 0 | +---------------+ 1 row in set (0.00 sec) If the sample you gave was auto-generated by the MyODBC driver it most likely compiled the WHERE clause because you don't have an unique primary key in your table. Best advise is to always add a primary key AUTOINC column to all tables. This will not only result in all your queries always being able to find the exact record, but will also reduce the traffic your current queries cause. The addition of an AUTOINC column is mainly due to MySQL's lack of server side cursors. This will be corrected it seems in MySQL 5, after which everyone will always be able to find their records independent of the data contained in the table. Kind Regards SciBit MySQL Team http://www.scibit.com MySQL Products: http://www.scibit.com/products/mycon http://www.scibit.com/products/mysqlcomponents http://www.scibit.com/products/mysqlx http://www.scibit.com/products/mascon > -----Original Message----- > From: "Luciano Pulvirenti" <[EMAIL PROTECTED]> > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > CC: > Subject: Serious error in update Mysql 4.1.7 > Sent: Fri, 03 Dec 2004 08:18:05 GMT > Received: Fri, 03 Dec 2004 08:22:55 GMT > Read: Fri, 03 Dec 2004 09:24:15 GMT > I am trying Mysql 4.1.7 before putting it in production in 4.0.16 > substitution on Windows NT. > I have found an anomaly for me serious. > I use Visual Basic 6 with ADO last version and the driver MYODBC 3.51.10. > The program produces the following query: > > UPDATE `paghe`.`anagpaghe` > SET `giorni_congedo_mp`=1.25000000000000000e+001, > `giorni_congedo_anno_prec_mp`=0.00000000000000000e+000, > `giorni_permessi_retrib_mp`=2.00000000000000000e+000, > `giorni_congedo`=1.15000000000000000e+001, > `giorni_congedo_anno_prec`=0.00000000000000000e+000, > `giorni_permessi_retribuiti`=2.00000000000000000e+000, > `swnuovo`=0 > WHERE `matricola`=43258 > AND `giorni_congedo_mp`=1.25000000000000000e+001 > AND `giorni_congedo_anno_prec_mp`=0.00000000000000000e+000 > AND `giorni_permessi_retrib_mp`=2.00000000000000000e+000 > AND `giorni_congedo`=1.15000000000000000e+001 > AND `giorni_congedo_anno_prec`=0.00000000000000000e+000 > AND `giorni_permessi_retribuiti`=2.00000000000000000e+000 > AND `swnuovo`=1 > > > Mysql doesn't succeed to update the record because no succeeds in finding > the record corresponding to the syntax WHERE. > I have made some tests have discover that the cause is > > AND `giorni_congedo`=1.15000000000000000e+001 > > In the version 4.0.16 work correctly. > The fields "giorni..." have declared in the structure double(5,1). > Thank you > > > > -- > Internal Virus Database is out-of-date. > Checked by AVG Anti-Virus. > Version: 7.0.290 / Virus Database: 265.4.3 - Release Date: 26/11/2004 > > > > -- > MySQL Windows Mailing List > For list archives: http://lists.mysql.com/win32 > To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED] > > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
