In php, an SQL statement is too long. during The debugging, it is found that the SQL statement has become incomplete and PHP experts can solve the problem for me:
An SQL statement is defined in php as follows:
$ SQL = "SELECT * FROM p_info pi LEFT JOIN job j ON j. id =". $ id.
"WHERE pi. requestid = 0
AND (ifnull (pi. standard_20_ft_container, 0)-ifnull (j. standard_20_ft_container, 0) <= 0)
AND (ifnull (pi. standard_40_ft_container, 0)-ifnull (j. standard_40_ft_container, 0) <= 0)
AND (ifnull (pi. high_cube_40_ft_container, 0)-ifnull (j. high_cube_40_ft_container, 0) <= 0)
AND (ifnull (pi. capacity_head_of_cattle, 0)-ifnull (j. capacity_head_of_cattle, 0) <= 0)
AND (ifnull (pi. capacity_head_of_sheep, 0)-ifnull (j. capacity_head_of_sheep, 0) <= 0)
AND (ifnull (pi. capacity_other_livestock, 0)-ifnull (j. capacity_other_livestock, 0) <= 0)
AND (ifnull (pi. capacity_number_of_horses, 0)-ifnull (j. capacity_number_of_horses, 0) <= 0)
AND (ifnull (pi. grain_feed_kg, 0)-ifnull (j. carrying_capacity_kg, 0) <= 0)
AND (ifnull (pi. length_cm, 0)-ifnull (j. tray_length_cm, 0) <= 0)
AND (ifnull (pi. width_cm, 0)-ifnull (j. tray_width_cm, 0) <= 0)
AND (ifnull (pi. height_cm, 0)-ifnull (j. max_load_height_cm, 0) <= 0)
AND (ifnull (pi. weight_kg, 0)-ifnull (j. carrying_capacity_kg, 0) <= 0)
AND to_days (j. home_day1) <= to_days (str_to_date (pi. date1, '% d/% m/% Y '))
AND to_days (str_to_date (pi. date2, '% d/% m/% Y') <= to_days (j. home_day2)
However, if the queried data is empty, it is found that the data is uploaded to $ query = mysql_query ($ SQL). the SQL statement here becomes like this:
SELECT * FROM p_info pi left join job j ON j. id = 734 WHERE pi. requestid = 0
AND (ifnull (pi. standard_20_ft_container, 0)-ifnull (j. standard_20_ft_container, 0) <= 0)
AND (ifnull (pi. standard_40_ft_container, 0)-ifnull (j. standard_40_ft_container, 0) <= 0)
AND (ifnull (pi. high_cube_40_ft_container, 0)-ifnull (j. high_cube_40_ft_container, 0) <= 0)
AND (ifnull (pi. capacity_head_of_cattle, 0)-ifnull (j. capacity_head_of_cattle, 0) <= 0)
AND (ifnull (pi. capacity_head_of_sheep, 0)-ifnull (j. capacity_head_of_sheep, 0) <= 0)
AND (ifnull (pi. capacity_other_livestock, 0)-ifnull (j. capacity_other_livestock, 0) <= 0)
AND (ifnull (pi. capacity_number_of_horses, 0)-ifnull (j. capacity_number_of_horses, 0) <= 0)
AND (ifnull (pi. grain_feed_kg, 0)-ifnull (j. carrying_capacity_kg, 0) <= 0)
AND (ifnull (pi. length_cm, 0)-ifnull (j. tray_length_cm, 0) <= 0)
AND (ifnull (pi. width_cm, 0)-ifnull (j. tray_width_cm, 0) <= 0)
AND (ifnull (pi. height_cm, 0)-ifnull (
It seems that the following SQL statement is truncated. it is okay to run the SQL statement in the database. But there is a problem here. what should I do? Do you have such a problem?
Reply to discussion (solution)
Amount... You haven't seen such a long SQL...
No more than one thousand points. There should be no problem. maybe you have stuck it wrong.
Suggestion:
1. The value field is not null but not null.
2. use this query to create a view
Amount... You haven't seen such a long SQL...
This is not long. you think it's all nonsense. because the database is unreasonable, I have to write it like this.
No more than one thousand points. There should be no problem. maybe you have stuck it wrong.
Suggestion:
1. The value field is not null but not null.
2. use this query to create a view
I found that the entered strings were incomplete during debugging. What is the reason. It is set to not null, but I am fixing a bug and cannot change the database. Wait for me to try the view.
It won't be truncated for no reason. debug it carefully.
Amount... You haven't seen such a long SQL...
This is not long. you think it's all nonsense. because the database is unreasonable, I have to write it like this.
Okay, var_dump outputs only a limited number of characters. you can echo the output and check if the two symbols are correct.
No more than one thousand points. There should be no problem. maybe you have stuck it wrong.
Suggestion:
1. The value field is not null but not null.
2. use this query to create a view
I found that the entered strings were incomplete during debugging. What is the reason. It is set to not null, but I am fixing a bug and cannot change the database. Wait for me to try the view.
I defined a string variable and assigned an SQL statement with a length over 1024. Incomplete value. Where can I improve it? let's look at this link. someone has the same problem with me:
Http://bbs.phpchina.com/thread-163748-1-1.html
It won't be truncated for no reason. debug it carefully.
This is the debugging result. The preceding definition is an SQL statement, and the result is passed to the query (). it is truncated with only 1024 characters.
Amount... You haven't seen such a long SQL...
This is not long. you think it's all nonsense. because the database is unreasonable, I have to write it like this.
Okay, var_dump outputs only a limited number of characters. you can echo the output and check if the two symbols are correct.
No, no, it defines an SQL statement and concatenates an ID. later, it is found that only 1024 of the SQL statement is intercepted during debugging.
At first glance, I didn't find a Chinese sentence inserted in the middle...
Someone has the same problem with me: http://bbs.phpchina.com/thread-163748-1-1.html
But that person has not already said:Resolved. Xdeubg bug. The program is not affected.?
Is that true for you?
At first glance, I didn't find a Chinese sentence inserted in the middle...
Well, I don't have a good layout, so you don't see it.
Someone has the same problem with me: http://bbs.phpchina.com/thread-163748-1-1.html
But that person has not already said:Resolved. Xdeubg bug. The program is not affected.?
Is that true for you?
After I commented out the xdebug configuration in php. ini, it still won't work.
That is to say, you have used xdebug, right?
Php does not limit the length of the query string. this can be illustrated by inserting an article into a table using the insert command.
Amount... You haven't seen such a long SQL...
This is not long. you think it's all nonsense. because the database is unreasonable, I have to write it like this.
Okay, var_dump outputs only a limited number of characters. you can echo the output and check if the two symbols are correct.
No, no, it defines an SQL statement and concatenates an ID. later, it is found that only 1024 of the SQL statement is intercepted during debugging.
Xdubug var_dump will be automatically truncated. I don't know if echo will happen. if xdebug is disabled, try again.
That is to say, you have used xdebug, right?
Php does not limit the length of the query string. this can be illustrated by inserting an article into a table using the insert command.
Yes, I used debug debugging, but I still cannot comment the debugging configuration in php. ini.
Are you sure you want to query whether it is null or an SQL statement error is returned? As you mentioned above, it is found that it is null, but the truncated SQL statement should report an error. Shouldn't this be determined first?
Is LZ the time for echo ??
If yes, we recommend that you write this statement into a table.
Are you sure you want to query whether it is null or an SQL statement error is returned? As you mentioned above, it is found that it is null, but the truncated SQL statement should report an error. Shouldn't this be determined first?
Hi, thank you. It is found to be empty. However, the same query statement shows a result set. I also think it should report an error. But I don't know much about php. In addition, the previous SQL statements have results in queries in the program. However, an error is returned when querying under navicat. I am confused about all this.
Is LZ the time for echo ??
If yes, we recommend that you write this statement into a table.
What do you mean? How to write data to a table?
I understand. here is the xdebug bug. it can only display 1024 bytes during debugging, but all the SQL statements you output are available.
