function queryTest2($objConn) {
if(!mysqli_query($objConn, "INSERT INTO testTable (cTekst) VALUES ('test')")) {
echo mysqli_error($objConn);
return false;
}else return true
}
My testTable contains only two columns "cTekst" and "cDate".
In the first test function I should be getting this error
Undefined variable: objResult
The second test function should give me this error
Field 'cDate' doesn't have a default value
But no.
The first just ignores the error, and returns true.
The second just inserts "test" and gives the cDate the value 0000-00-00.
My external rental server works as it should, but not my home testing server. Anyone know what this could be?
My home server runs:
Ubuntu Server 9.10
Apache 2.2.12
PHP 5.3.0
MySQL 5.1
When I make mistakes I expect my server to complain about it and not just go along with it.
And yes, Error messaging is activated and set to display all errors, warnings etc. and it usually works, just not with these two error types apparently.
What exactly do you have in your php.ini as a value for display_errors? The first would be a notice level error so E_ALL should cover it I'd have thought. The second one I wouldn't necessarily expect an error unless the column has the NOT NULL flag set.
This is all the error related settins from my php.ini
Code:
error_reporting = E_ALL | E_STRICT
display_errors = On
display_startup_errors = On
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
track_errors = On
...The second just inserts "test" and gives the cDate the value 0000-00-00....
That would be strictly a MySQL issue -- nothing to do directly with PHP. It would seem to imply that on that test platform that cDate is not specified NOT NULL in the table definition.
I realize that does not fix anything for you, but it makes me wonder if there is some disconnect here, such as editing the wrong include file or something (e.g. in a different directory from the one that is actually being included)? (Not that I would ever have done something like that. )
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
As to the nulls thing, my understanding of it is if you don't define the value in the insert, MySQL considers this an implicit NULL and will use the default value. If no default value is set MySQL defines one internally based on the column type.
I tested on my own table doing what you did, it inserted without complaining with a date field set to not allow null and either a default value set or not.
but it makes me wonder if there is some disconnect here, such as editing the wrong include file or something (e.g. in a different directory from the one that is actually being included)?
Do you mean that I update the wrong table?
That would be possible, except that what I insert appears in the correct table
And according to phpmyadmin's structure output, the cDate column should be specified NOT NULL.
As to the nulls thing, my understanding of it is if you don't define the value in the insert, MySQL considers this an implicit NULL and will use the default value. If no default value is set MySQL defines one internally based on the column type.
I tested on my own table doing what you did, it inserted without complaining with a date field set to not allow null and either a default value set or not.
I don't know how the correct way for MySQL to behave is, and actually I don't care if it should or should not generate an error in this example. What I do care about however, is that when I test my things on my server, I can be sure that it will work on others to.
I think it's suck pretty much to use hours on testing, and then have my work generate errors on other servers because my setup did not care about the mistakes I made. The point of testing is to correct possible mistakes. But that's not easy if the mistakes is ignored :S
Last edited by dk_zero-cool; 01-28-2010 at 02:25 PM.
Is your sandbox MySQL the exact same version and platform as on your production server?
If not, you might have found an issue between two versions or platforms in this specific testing scenario. Also, most importantly, not all SQL servers are the same, i.e. some interpret the null as implicit in the insert situation, others explicitly (when a null really is a null). MySQL is not ANSI SQL through and through, either.
Your pain is understood, just trying to get to the bottom of this.
-jim
Last edited by SrWebDeveloper; 01-28-2010 at 02:29 PM.
Reason: added link
Is your sandbox MySQL the exact same version and platform as on your production server?
Hmm, no.
Mine is: 5.1.37
The other is: 5.1.42-community
MySQL is not ANSI SQL through and through if you follow what I'm saying.
Sure
But what about the PHP error.
I think that we can agree that trying to use an undefined variable in an mysqli_num_rows function would produce one of two errors. Either an undefined variable error or an error for trying to use the mysqli_num_rows function without any result link?
No, I was just speculating whether the PHP file that was being executed (e.g. included) was not the one you were editing. It happened to me once, and I spent maybe an hour of wasted time before I realized it.
I'm guessing it's more likely though, from the combination of problems, is that there is some version and/or configuration difference(s), but I thought it was worth double-checking before you start digging into config files, installing new versions, etc. (though ultimately it is desirable to have your test bed be as close to the production environment as possible, other than having display_errors turned on on the test bed, perhaps).
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
(though ultimately it is desirable to have your test bed be as close to the production environment as possible, other than having display_errors turned on on the test bed, perhaps).
I think a test bed should be as strict as possible to be as sure that production environments will not encounter any problems.
Turning errors off on a test machine would not be a good idea.
No, I was saying to have display_errors turned on on the test/development machine, while you will likely want it turned off on the production version. (At least that's what I was trying to say.) Setting the error_reporting level to as strict as you want it on the test host, as you point out, is a good idea, too.
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
I haven't updated locally to PHP 5.3.x yet, as nothing I've been working on has been later than 5.2.x.
Anyway, wish I could tell you what the original problem was, but I'm glad you got it fixed, hopefully.
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
Reply With Quote
)
Originally Posted by dk_zero-cool
Bookmarks