Here is some trivial code: $n= db_query($countsql) ; echo "<!-- ";print_r(db_fetch_array($n)); echo " -->"; $countsql = str_replace('{','',$countsql); $countsql = str_replace('}','',$countsql); $resultXXX = mysql_query($countsql); echo "<!-- ";print_r(mysql_fetch_array($resultXXX)); echo " -->"; which runs my $countsql through db_query, shows the result and then through mysql_query and shows the results. The two other lines just remove the { and } characters. I would have expected to see the same results both times, but what I see is: <!-- Array ( [COUNT(*)] => 0 ) --><!-- Array ( [0] => 4 [COUNT(*)] => 4 ) --> The mysql_query version returns the correct result--that is what I see if I run the query via phpMyAdmin as well. Seems that Drupal's db_query is doing something to it. The operative issue is the use of UCASE I am quite certain. I wanted to make my LIKE phrase case insensitive, so I added UCASE to both sides of it, but now db_query fails. Anyone have any feedback on this? I would not be opposed to just using mysql_query but the query in question I actually want to pass to pager_query, which in turn of course passes it to db_query. Thanks.
Why you are using mysql in that ?? I thing that also is the error On Mon, Sep 22, 2008 at 4:36 PM, Fred Jones <fredthejonester@gmail.com>wrote:
Here is some trivial code:
$n= db_query($countsql) ; echo "<!-- ";print_r(db_fetch_array($n)); echo " -->"; $countsql = str_replace('{','',$countsql); $countsql = str_replace('}','',$countsql); $resultXXX = mysql_query($countsql); echo "<!-- ";print_r(mysql_fetch_array($resultXXX)); echo " -->";
which runs my $countsql through db_query, shows the result and then through mysql_query and shows the results. The two other lines just remove the { and } characters. I would have expected to see the same results both times, but what I see is:
<!-- Array ( [COUNT(*)] => 0 ) --><!-- Array ( [0] => 4 [COUNT(*)] => 4 ) -->
The mysql_query version returns the correct result--that is what I see if I run the query via phpMyAdmin as well. Seems that Drupal's db_query is doing something to it. The operative issue is the use of UCASE I am quite certain. I wanted to make my LIKE phrase case insensitive, so I added UCASE to both sides of it, but now db_query fails.
Anyone have any feedback on this? I would not be opposed to just using mysql_query but the query in question I actually want to pass to pager_query, which in turn of course passes it to db_query.
Thanks. -- [ Drupal support list | http://lists.drupal.org/ ]
I am trying to find out how to get Youtube Video 4.7.x-1.0 to work. I fill in : the title youtube video url disabel rich text in the teaser and embedd the code from youtube inside the tags:<pre></pre>, I do the same in the body section. I have changed the size of youtube video to fit the block at my site. Since I do not want to show the youtube movie in full size as at youtube. What happens is that the video does not show up, only an X where the video ws supposed to be. What am I doing wrong? Any advice? Google Video 4.7.x-1.0 Enable Google video support for Video module. Depends on: Video (enabled) Upload Video 4.7.x-1.0 Enable Uploaded video support for Video module. Depends on: Video (enabled), Token (enabled) Required by: Video ffmpeg Helper (enabled) URL Video 4.7.x-1.0 Enable URL video support for Video module. Depends on: Video (enabled) Video 4.7.x-1.0 Allows video nodes. Required by: Video Custom Fields (enabled), Video ffmpeg Helper (enabled), Google Video (enabled), Video Image (enabled), Video Multidownload (enabled), Video Opt Metadata (enabled), Video Params (enabled), Upload Video (enabled), URL Video (enabled), Youtube Video (enabled) Video Custom Fields 4.7.x-1.0 Enable addition of custom fileds on video nodes created by video module. Depends on: Video (enabled) Video ffmpeg Helper 4.7.x-1.0 Provide apis for ffmpeg. Simplify video nodes creation. Depends on: Video (enabled), Upload Video (enabled) Video Image 4.7.x-1.0 Enable thumbnails support for video module. Depends on: Image (enabled), Video (enabled) Video Multidownload 4.7.x-1.0 Enable multiple file download in video module. Depends on: Video (enabled) Video Opt Metadata 4.7.x-1.0 Enable addition of optional metadata on video nodes created by video module. Optional metadata are Video Bitrate, Audio Bitrate, Audio Sampling Rate and Audio Channels. Depends on: Video (enabled) Video Params 4.7.x-1.0 Enable addition of html params to object generated by video module. Useful if you need to use swf videos which needs params to be passed. Depends on: Video (enabled) Youtube Video 4.7.x-1.0 Enable Youtube videos support for Video
Am Montag, 22. September 2008 21:00:37 schrieb Gina Rydland:
I am trying to find out how to get Youtube Video 4.7.x-1.0 to work.
I fill in : the title youtube video url disabel rich text in the teaser and embedd the code from youtube inside the tags:<pre></pre>, I do the same in the body section.
I have changed the size of youtube video to fit the block at my site. Since I do not want to show the youtube movie in full size as at youtube.
What happens is that the video does not show up, only an X where the video ws supposed to be.
What am I doing wrong?
are you using "filtered html" or "HTML" ? Sebastian -- Science is what happens when preconception meets verification.
Hi! I am using full HTML --- On Tue, 9/23/08, Sebastian Gödecke <simpsonetti@googlemail.com> wrote: From: Sebastian Gödecke <simpsonetti@googlemail.com> Subject: Re: [support] Youtube Video 4.7.x-1.0 To: support@drupal.org Date: Tuesday, September 23, 2008, 8:30 AM Am Montag, 22. September 2008 21:00:37 schrieb Gina Rydland:
I am trying to find out how to get Youtube Video 4.7.x-1.0 to work.
I fill in : the title youtube video url disabel rich text in the teaser and embedd the code from youtube inside the tags:<pre></pre>, I do the same in the body section.
I have changed the size of youtube video to fit the block at my site. Since I do not want to show the youtube movie in full size as at youtube.
What happens is that the video does not show up, only an X where the video ws supposed to be.
What am I doing wrong?
are you using "filtered html" or "HTML" ? Sebastian -- Science is what happens when preconception meets verification. -- [ Drupal support list | http://lists.drupal.org/ ]
It really depends on what $countsql is. Is your query being rewritten by db_query_rewrite? -Mike On Sep 22, 2008, at 6:06 AM, Fred Jones wrote:
Here is some trivial code:
$n= db_query($countsql) ; echo "<!-- ";print_r(db_fetch_array($n)); echo " -->"; $countsql = str_replace('{','',$countsql); $countsql = str_replace('}','',$countsql); $resultXXX = mysql_query($countsql); echo "<!-- ";print_r(mysql_fetch_array($resultXXX)); echo " -->";
which runs my $countsql through db_query, shows the result and then through mysql_query and shows the results. The two other lines just remove the { and } characters. I would have expected to see the same results both times, but what I see is:
<!-- Array ( [COUNT(*)] => 0 ) --><!-- Array ( [0] => 4 [COUNT(*)] => 4 ) -->
The mysql_query version returns the correct result--that is what I see if I run the query via phpMyAdmin as well. Seems that Drupal's db_query is doing something to it. The operative issue is the use of UCASE I am quite certain. I wanted to make my LIKE phrase case insensitive, so I added UCASE to both sides of it, but now db_query fails.
Anyone have any feedback on this? I would not be opposed to just using mysql_query but the query in question I actually want to pass to pager_query, which in turn of course passes it to db_query.
Thanks. -- [ Drupal support list | http://lists.drupal.org/ ]
__________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net
http://api.drupal.org/api/function/db_fetch_array/5 Drupal's db_fetch_array functions use *_fetch_assoc() internally. In ext/mysql and ext/pgsql, *_fetch_array() returns a doubly indexed array by field AND number. *_fetch_assoc() returns just the associative array. I have frankly never seen a reason to want the doubly indexed version, so it's good that Drupal gives you the version that makes sense. :-) You should be opposed to using mysql_* directly, as that is the Wrong Way(tm) to access the database. That bypasses all of the Drupal security handling and is an SQL Injection risk. In this case, in fact, you probably don't want a fetch at all. You just want the single count value. $count = db_result(db_query($countsql)); And you're done. --Larry Garfield On Mon, 22 Sep 2008 13:06:14 +0200, "Fred Jones" <fredthejonester@gmail.com> wrote:
Here is some trivial code:
$n= db_query($countsql) ; echo "<!-- ";print_r(db_fetch_array($n)); echo " -->"; $countsql = str_replace('{','',$countsql); $countsql = str_replace('}','',$countsql); $resultXXX = mysql_query($countsql); echo "<!-- ";print_r(mysql_fetch_array($resultXXX)); echo " -->";
which runs my $countsql through db_query, shows the result and then through mysql_query and shows the results. The two other lines just remove the { and } characters. I would have expected to see the same results both times, but what I see is:
<!-- Array ( [COUNT(*)] => 0 ) --><!-- Array ( [0] => 4 [COUNT(*)] => 4 ) -->
The mysql_query version returns the correct result--that is what I see if I run the query via phpMyAdmin as well. Seems that Drupal's db_query is doing something to it. The operative issue is the use of UCASE I am quite certain. I wanted to make my LIKE phrase case insensitive, so I added UCASE to both sides of it, but now db_query fails.
Anyone have any feedback on this? I would not be opposed to just using mysql_query but the query in question I actually want to pass to pager_query, which in turn of course passes it to db_query.
Thanks. -- [ Drupal support list | http://lists.drupal.org/ ]
I must be misunderstanding the issue .. I understood the OP's use of mysql_* as simply being for demonstrative purposes to show the difference in the returned results, and the actual question being why does db_query return a result of 0 for COUNT(*) when mysql_query returns a result of 4 for COUNT(*). I'd also like to know what the actual string value of $countsql is, and like Michael said, whether the query is being rewritten by another module. On Mon, Sep 22, 2008 at 6:04 PM, Larry Garfield <larry@garfieldtech.com>wrote:
http://api.drupal.org/api/function/db_fetch_array/5
Drupal's db_fetch_array functions use *_fetch_assoc() internally. In ext/mysql and ext/pgsql, *_fetch_array() returns a doubly indexed array by field AND number. *_fetch_assoc() returns just the associative array. I have frankly never seen a reason to want the doubly indexed version, so it's good that Drupal gives you the version that makes sense. :-)
You should be opposed to using mysql_* directly, as that is the Wrong Way(tm) to access the database. That bypasses all of the Drupal security handling and is an SQL Injection risk.
In this case, in fact, you probably don't want a fetch at all. You just want the single count value.
$count = db_result(db_query($countsql));
And you're done.
--Larry Garfield
On Mon, 22 Sep 2008 13:06:14 +0200, "Fred Jones" < fredthejonester@gmail.com> wrote:
Here is some trivial code:
$n= db_query($countsql) ; echo "<!-- ";print_r(db_fetch_array($n)); echo " -->"; $countsql = str_replace('{','',$countsql); $countsql = str_replace('}','',$countsql); $resultXXX = mysql_query($countsql); echo "<!-- ";print_r(mysql_fetch_array($resultXXX)); echo " -->";
which runs my $countsql through db_query, shows the result and then through mysql_query and shows the results. The two other lines just remove the { and } characters. I would have expected to see the same results both times, but what I see is:
<!-- Array ( [COUNT(*)] => 0 ) --><!-- Array ( [0] => 4 [COUNT(*)] => 4 ) -->
The mysql_query version returns the correct result--that is what I see if I run the query via phpMyAdmin as well. Seems that Drupal's db_query is doing something to it. The operative issue is the use of UCASE I am quite certain. I wanted to make my LIKE phrase case insensitive, so I added UCASE to both sides of it, but now db_query fails.
Anyone have any feedback on this? I would not be opposed to just using mysql_query but the query in question I actually want to pass to pager_query, which in turn of course passes it to db_query.
Thanks. -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
I must be misunderstanding the issue .. I understood the OP's use of mysql_* as simply being for demonstrative purposes to show the difference in the returned results, and the actual question being why does db_query return a result of 0 for COUNT(*) when mysql_query returns a result of 4 for COUNT(*).
That is precisely correct.
I'd also like to know what the actual string value of $countsql is, and like Michael said, whether the query is being rewritten by another module.
Yes, it is rewritten I believe. Here is the actual code in question: $r = pager_query($sql,10,0,$countsql); $rows = array(); $output = ''; while ($row = db_fetch_array($r)) { $rows[] = $row; } if (0 == count($rows)) { $output = '<p>No results found</p>'; } I am getting the "No results found" whereas there should be 4 rows found. That last if has an else clause to display those, when found. Here is the SQL: SELECT COUNT(*) from (SELECT field_article_title_value FROM (SELECT content_type_book.field_article_title_value, term_node.tid, node_revisions.nid FROM (( node_revisions left join node on node.nid = node_revisions.nid ) left join content_type_book on content_type_book.nid = node_revisions.nid ) left join term_node on term_node.nid = node_revisions.nid WHERE (1=1) and ((UCASE(content_type_book.field_article_author_value) like UCASE('%Black%'))) and (1=1) and (1=1) and node.type='book' group by node_revisions.nid order by node_revisions.nid ) as XXXXX group by field_article_title_value, tid order by nid ) as temp_table; Thanks.
I'd also like to know what the actual string value of $countsql is, and like Michael said, whether the query is being rewritten by another module.
The other option appears to be to change the collation of the table(s) in question. According to this: http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html certain collations are automatically case insensitive. I had initially hesitated to make such a change to the schema, but it appears to be an option if my current approach fails. Fred
participants (8)
-
bharani kumar -
Fred Jones -
Gina Rydland -
janni frento -
Larry Garfield -
Michael Prasuhn -
Sebastian Gödecke -
William Smith