Ok guys, I found the problem. It's actually something I've run into
before. If you take a look at the query you'll notice that one of the
fields is named "returns". When I created the test table with phpMyAdmin
it created it and everything seemed fine. Then I decided to try
something. I tweaked my install script to add creation of the new log
table and ran it. It failed on that field. When I changed the name of
the field it worked. I've seen this before when I tried to create a
field for another database called "group". Apparently these are MySQL
reserved words and you can't use them as names for fields. Go figure.
Anyway, that solves the problem. When I run it the data is put into the
table, and the line where I echo the $logit var displays a 1. By the
way, I changed the name of the returns field to "found".
------------
just as an FYI, although i would have changed the name as well, if you're
using, or think you are using, a reserved word, you can enclose it in
`backticks` and mysql will treat it as a regular word, which is how
PHPMyAdmin creates and uses all fields. That being said, your solution of
changing the field is better.
Jeff
-------------
Nick
Micah Stevens wrote:
>Right.. a resource.. sorry.
>
>On Thursday 26 February 2004 12:55 pm, jeffrey_n_Dyke@xxxxxxxxx wrote:
>
>
>>An interesting thought. I tried this:
>>
>>echo "Term: $search, Returns: $arrayword, UserIP: $ip<br>";
>>$logit = mysql_query("INSERT INTO log SET term='$search',
>>returns='$arrayword', time=CURTIME(), date=CURDATE(), ip='$ip'");
>>echo "Query Value: $logit";
>>
>>And got this on the page:
>>
>>Term: skater, Returns: 312, UserIP: 192.168.1.234
>>Query Value:
>>
>>
>>-----
>>mysql_query returns a Resource, which is not a printable 'string', You
>>could print_r($logit), or var_dump($logit) and you would most likely see
>>Resouce ID #3 (or some other number). So even if you're query excecutes
>>properly printing $logit will always show as you've written above. The
>>same would hold true of an array, when just using print.
>>
>>the returned value preceeds the function call in the manual.
>>from php.net/mysql_query
>> resource mysql_query ( string query [, resource link_identifier])
>>
>>
>>hth
>>jeff
>>-----
>>
>>
>>Notice that the variables are set with appropriate values, but the
>>$logit variable is blank. This, I think is the problem. The question is
>>why would it do this and not return any type of error? By the way, I
>>tried this using the other syntax people where suggesting and I got the
>>same results. I gotta tell you, this one is really kicking my ass. It's
>>the last piece of an update that I can't release until it's finished.
>>
>>Nick
>>
>>Hutchins, Richard wrote:
>>
>>
>>>Been kind of following this thread off and on...
>>>
>>>If the syntax is acceptable by MySQL, which it appears to be, is it
>>>
>>>
>>possible
>>
>>
>>
>>>that the variables you are using within the query string are not set to
>>>anything? Or is it possible that there is something broken immediately
>>>before the query string is fired?
>>>
>>>Most times, when I run into query problems, immediately before I send
the
>>>query to the database, I'll echo the statement out to the browser so I
can
>>>see the exact string that's being sent to the db.
>>>
>>>So can you do this:
>>>
>>>$sql = "INSERT INTO log SET term='$search', returns='$arrayword',
>>>time=CURTIME(), date=CURDATE(), ip='$ip'";
>>>
>>>echo $sql;
>>>
>>>$logit = mysql_query($sql) or
>>> die(mysql_error());
>>>
>>>
>>>And check out what gets spit out to the browser when $sql is echoed?
Maybe
>>>that'll point out something that's going wrong. If nothing is apparent,
>>>
>>>
>>post
>>
>>
>>
>>>the results of echo $sql back to the list and maybe one of us will find
>>>something.
>>>
>>>HTH.
>>>
>>>Rich
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Axel IS Main [mailto:nfzgrld@xxxxxxxxxx]
>>>>Sent: Thursday, February 26, 2004 2:37 PM
>>>>To: PHP DB
>>>>Subject: Re: What's wrong with this query?
>>>>
>>>>
>>>>Ok, ok. I get the message about the syntax. Since I've used
>>>>this syntax
>>>>for a long time and so far there hasn't been a problem I'll assume
>>>>that's not the problem. I will, however, review this and
>>>>probably make
>>>>some changes for the sake of compliance if nothing else. In
>>>>any event,
>>>>the syntax is NOT why it is failing, smart ass comments by people who
>>>>think two years is a long time not withstanding.
>>>>
>>>>As to the useful questions that where asked. There is no
>>>>error reported.
>>>>Error reporting is set to E_ALL & ~E_NOTICE. I removed the
>>>>notice part
>>>>so I would get everything and still nothing showed up. I'm
>>>>also logging
>>>>errors and nothing is showing up in the log either. Not all PHP/MySQL
>>>>errors are reported. Sometimes what happens is not considered
>>>>an error,
>>>>even though it does not do what you would expect it to do. If
>>>>the query
>>>>syntax was wrong, I would get a syntax error. There is no
>>>>error, it just
>>>>doesn't write to the table. I can go into phpMyAdmin and with
>>>>the same
>>>>syntax insert into the table all day long.
>>>>
>>>>--
>>>>PHP Database Mailing List (http://www.php.net/)
>>>>To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>>>>
>
>
>
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
