Re: Very Strange data corruption

Michael Stassen wrote: This comes up frequently. MySQL's behavior is explained in the manual . It begins: That's interesting, and I guess one just has to accept it as part of the mysql philosphy. I don't agree, as I don't like the data

Re: Very Strange data corruption

This comes up frequently. MySQL's behavior is explained in the manual . It begins: | To be able to support easy handling of non-transactional tables, all | columns in MySQL have default values. | | If you insert an ``incorrect'' value i

RE: Very Strange data corruption

From: Steve Meyers [mailto:[EMAIL PROTECTED] > David Griffiths wrote: > > I'm not sure what the sql standard says on the matter, but > Oracle, DB2 > > and Postgres would through an exception. In fact, there is > a page on > > MySQL "gotachs" to document MySQL behaviour when it differs > > sig

Re: Very Strange data corruption

David Griffiths wrote: But the reason modern databases have foreign keys, primary keys, not-nulls, check constraints and data-metadata (char(5), INT, BIGINT, etc) is to prevent bad data from going in.. If no exception is thrown because you are trying to put a BIGINT into an INT, then why throw o

Re: Very Strange data corruption

[EMAIL PROTECTED] cc: Subject: Re: Very Strange data corruption It's best practice to write unit tests for all your code, with calculated data to show what you expect. That data then gets compared to what is actually generated and if there is a discrepency, then you have

Re: Very Strange data corruption

David Griffiths wrote: I'm not sure what the sql standard says on the matter, but Oracle, DB2 and Postgres would through an exception. In fact, there is a page on MySQL "gotachs" to document MySQL behaviour when it differs significnatly from other databases (like the first datetime field in a t

Re: Very Strange data corruption

The client software ought to be range-checking the data before sending it to the database. If the client isn't even doing that kind of minimal-effort check, how likely is it to be checking for exceptions? Not sure what you code in, but in Java, you *HAVE* to catch SQLExceptions (or throw them

Re: Very Strange data corruption

David Brodbeck wrote: The client software ought to be range-checking the data before sending it to the database. If the client isn't even doing that kind of minimal-effort check, how likely is it to be checking for exceptions? That's not to say that an error or exception is a bad idea, but MySQL

Re: Very Strange data corruption

It's best practice to write unit tests for all your code, with calculated data to show what you expect. That data then gets compared to what is actually generated and if there is a discrepency, then you have a bug somewhere. But the reason modern databases have foreign keys, primary keys, not-

(U) RE: Very Strange data corruption

CLASSIFICATION: UNCLASSIFIED who knows -Original Message- From: Mike Johnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 25, 2004 12:26 PM To: David Griffiths; [EMAIL PROTECTED] Subject: RE: Very Strange data corruption From: David Griffiths [mailto:[EMAIL PROTECTED] > MySQL rea

Re: Very Strange data corruption

David Griffiths wrote: MySQL really should throw an exception/error rather than just quietly trim your data and accept it. When your data is critical, and your business depends on it, you can't have bad data quietly going into the database. David. Mike Johnson wrote: A value is not valid just

RE: Very Strange data corruption

> -Original Message- > From: David Griffiths [mailto:[EMAIL PROTECTED] > MySQL really should throw an exception/error rather than just quietly > trim your data and accept it. When your data is critical, and your > business depends on it, you can't have bad data quietly going > into th

RE: Very Strange data corruption

From: David Griffiths [mailto:[EMAIL PROTECTED] > MySQL really should throw an exception/error rather than just quietly > trim your data and accept it. When your data is critical, and your > business depends on it, you can't have bad data quietly going > into the > database. Someone correct m

Re: Very Strange data corruption

MySQL really should throw an exception/error rather than just quietly trim your data and accept it. When your data is critical, and your business depends on it, you can't have bad data quietly going into the database. David. Mike Johnson wrote: From: Jeff McKeon [mailto:[EMAIL PROTECTED] Que

RE: Very Strange data corruption

or all the explanations.. Jeff > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 25, 2004 2:41 PM > To: Jeff McKeon > Cc: [EMAIL PROTECTED] > Subject: Re: Very Strange data corruption > > > > Jeff, > > You are try

Re: Very Strange data corruption

05/25/2004 02:29 Subject: Very Strange data corruption

RE: Very Strange data corruption

From: Jeff McKeon [mailto:[EMAIL PROTECTED] > Query: > > insert into > MIS.simcard(ID,ShipID,Service_Provider,SN,v1,v2,f1,d1,puk1,puk > 2,pin1,pin > 2,TwoStage,Status,DateAssigned,DateDisabled,UserID) > VALUES('NULL', '6889927707', '1', '8988169214000421398', > '881621456175', > '', '', '88169

Re: Very Strange data corruption

Set the fieldtype to 'bigint' It's the limit on int "Jeff McKeon" <[EMAIL PROTECTED]> 05/25/2004 02:29 PM To: <[EMAIL PROTECTED]> cc: Subject:Very Strange data corruption Query: insert into MIS.simcard(ID,ShipID

Very Strange data corruption

Query: insert into MIS.simcard(ID,ShipID,Service_Provider,SN,v1,v2,f1,d1,puk1,puk2,pin1,pin 2,TwoStage,Status,DateAssigned,DateDisabled,UserID) VALUES('NULL', '6889927707', '1', '8988169214000421398', '881621456175', '', '', '881693156175', '62982149', '', '', '', '1307', '1', '1085508771',