phdphd

Actually #[^[:alnum:]]# will accept "hello world öÄßáéíóúÁÉÍÓÚüÜñÑ" or just "öÄßáéíóúÁÉÍÓÚüÜñÑ" but not just "world". It seems it needs at least one "special" character (that could be a space). I think I finally found the solution by combining both regexes. The one below accepts strings like "solution", "öÄáéíóúÁÉÍÓÚ" and "a f öÄßáéíóúÁÉÍÓÚ t üÜz z z z ñÑ dsd dfd ?! hope I found the solution now :-(" "[^[:alnum:]]|[[:alnum:]]"

Finally #[^[:alnum:]]# did the job.

Hi All, I am trying to set up a pregmatch that validates some data entered by the user. Since my website is intended to any European-language speaking people (including German, Swedish, Spanish, etc.), I am testing it with a string that contains characters from most of those languages. I initially thought that a simple #[[:alnum:]]# would do the job. It actually works fine for English, French and Spanish, but it still does not accept the test string. Any help welcome. Thanks !

Hi All, I have a web page where I load a radio-button list of about 10000 cities. This list appears in a vertically scrolling zone. To get the list as much visually uncluttered as possible, every city name appears "alone", however under the hood every city name is associated with a radio button. Basically every city name has the following formatting : <li><input style="display:none;" type="radio" name="rb_group_name" value="[city_name]" id="[city_id]" onclick="this.form.submit()"><label style="cursor:pointer" for="[city_id]"><span class="name_format">[city_name]</span></label></li> The name_format class is associated with some css that determines the aspect of a city name according to its state (not hovered using the mouse/hovered). This page takes only a few seconds to load in FF, Chrome, Opera, and even in - though not as fast- Safari. But in IE 10, it takes up to 30 seconds for the city list to be actually scrollable, even though it is populated. I tried to reset the IE settings to their default values, and to disable add-ons, but this did not help. (I noticed that refreshing the page in IE is as fast as first loading in others browsers. However, clicking "back" button+calling the page again from localhost results in the same issue.) Thanks in advance for your help!

Very interesting. I am going to investigate key caching. I think I understand why in PHPMyAdmin even the first execution is fast. Actually I think it is just an illusion, in the sense that the time that the php script takes to gather all the indexes is apparently taken by PHPMyAdmin when one selects the database (by clicking on its name) before running the query manually under the SQL tab.

Hi All, Me again, sorry . First of all I'd like to thank all of you for your patience and time dedicated to my issue, I really appreciate it, even if so far we have not found the solution. On my side I keep testing. I've just noticed something strange : assuming that my query contains SQL_NO_CACHE and that I run it through the php script, the first execution will last very long (generally between 1 to 3 minutes). If I reload the php page, I noticed the execution lasts only one second. At first I thought the recordset could be cached somewhere else than in the query cache. So to clarify this I tried to make a slight change to my query : trying another partition. And against the new partition, the query ran as quick as when reloading. It is like if on the first execution the query wanted to "make acquaintance" (sort of indexing?) with all of the partitions. I would like to know your opinion on this. Thanks.

Yes, this is a true representation of the query. However table1.fieldX does not represent the same data as table2.fieldX. The reason for partition is that table1 contains 4 millions records, and the partition "only" about 400k.

The code I initially posted was complete and actual code. I just changed it a bit when I was asked if I was sure the recordset was the same in both cases. I was 100% sure it was, but to satisfy the request I just added a while loop with an echo line to have the results displayed in the browser and have the visual proof that the recordset returned there was the same as the one returned in phpmyadmin. Yes I use the same database username in phpmyadmin and in my php code.

Here are the explain outputs, reformatted for better readability. The first two lines represent the output in phpmyadmin, as displayed by phpmyadmin. The last two lines represent the output as displayed in firefox, using a while loop in the php script with an echo line that displays the contents of each column. The only difference is that while the output from phpmyadmin displays "null" for the last field (Extra) of the second line, the output in firefox displays nothing. id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE events ref PRIMARY,fk_events_cns1,city,cn_city cn_city 334 const,const 3844 Using where; Using index; Using temporary 1 SIMPLE event_crit ref fk_event_crit_events1,crit_pert fk_event_crit_events1 4 mydb.events.event_id 21 NULL 1 SIMPLE events ref PRIMARY,fk_events_cns1,city,cn_city cn_city 334 const,const 3844 Using where; Using index; Using temporary 1 SIMPLE event_crit ref fk_event_crit_events1,crit_pert fk_event_crit_events1 4 mydb.events.event_id 21 EDIT: Oops, seems the table formatting did not work. I hope the data are still relevant anyway.

Sorry, I am on windows.

the magic happening for me would be getting the results through the php script as quick as from within phpmyadmin :-(

There are no differences in query plans between methods.

Yes I am sure the results are the same, exactly 33 records in both cases (in the php script, I use a while loop with an echo line that displays the contents of the 2 fields record by record).

I confirm that with SQL_NO_CACHE and after computer rebooting+server starting, the results are returned immediately. Yes. Yes.

As I said earlier to get objective results I always run the query after rebooting the computer and restarting the server, so that no previously cached data is available. I confirm that the query returns results immediately from within phpmyadmin.

mysqli does not really help. I am not sure that php is the "guilty" part indeed. If I run the query in a standalone mode from within FlySpeed SQL Query, it still takes a very long time to run. So , so far, it just works as expected when executed from within PHPMyAdmin.

Yes, the PHP code I posted is the complete code. Actually it is just aimed at sending the query and measuring the time elapsed for processing the query. If I just change the query line to a query that runs against a non partitioned table but equivalent in size and in number of records to be returned, the same results are returned in a couple of seconds. My feeling is that when running against the partitioned table, all partitions are parsed, instead of the mentioned partition being directly queried. In UwAmp, in PHP settings dialog box, both php_mysql.dll and php_mysqli.dll are enabled. In phpmyadmin, in "Web Server" section, mysqli is mentioned as a PHP extension. The same section also indicates "Apache/2.2.22". Also when I open http://localhost/partition_vs_non_partition/ page, "Apache/2.2.22 (Win32) PHP/5.4.15 Server at localhost Port 80" appears at the end of the page.

Putting "127.0.0.1" instead of "localhost" does not help. Also with "localhost", If I run the same query through a php script against a non-partitioned similar-size table, the query is very quick. There seems to be an issue with php dealing with partitioned tables.

Hi All, I am facing a situation where the exactly same query is very quick from within phpmyadmin (less than 1s) and very slow through a php script (up to 2 minutes). To obtain objective measures, in both cases, the query is executed only after restarting the computer, and turning the server on. The environment is mysql 5.6.11/php 5.4.15. This query returns just 33 records. It runs against a partitioned table and contains an inner join with another table. The php test script structure is very simple : $connexion = mysql_connect(...); mysql_select_db('db', $connexion) $time = microtime(TRUE); $sql = 'SELECT distinct `field1`, ` field2` FROM `table1` partition (p1) Inner Join table2 On table1.id=table2.id Where table2.field1 = "something" And table2.field2 = " something_else"'; $rs = mysql_query($sql, $connexion); echo '<pre>'; print_r(array('time elapsed' => microtime(TRUE) - $time)); echo '</pre>'; mysql_close($connexion); Is there something wrong on PHP's side ? Thanks !

And the winner is .... David ! The warning I get is of type "Cannot modify header information - headers already sent by (output started at C:\UwAmp\www\.....\page.php:XX) in C:\UwAmp\www\.....\page.php.php on line YY...." At XX level, there is print_r($_SESSION);, while YY corresponds to the line where the header('Location: page.php') is located. I solved the issue by setting output_buffering to On in the php.ini file. Thank you very much David!

To set them, $_SESSION['var_name']=var_value; To check them, echo '<pre>'; print_r($_SESSION); echo '</pre>';

Even with session_write_close(); inserted before the "header('Location: page.php');" statement, the session variables still get lost.

Hi All, I am facing a strange problem with session variables being partially lost after redirect. I recently moved from a wampserver/php 5.3.5 environment to a UwAmp/php 5.4.15 environment. I am using the same php files and scripts in both environments. In one of the scripts there are session variables being set and also a "header('Location: page.php');" statement. Everything works perfectly in the older environment. However, in the newer one, session variables belonging to the same script as the "header('Location: page.php');" statement are lost, while all other session variables previously set in other scripts are kept. The problem persists if I use a UwAmp/php 5.3.5 environment. Any idea of where the problem comes from ? Thanks!

another good piece of news !

Hi All, FYI I installed mysql 5.6 on an old 32-bit laptop and I am impressed by the power of partitioning in mysql 5.6, compared to partitioning in mysql 5.5. Despite the less powerful architecture (32 bits instead of 64 bits), select time has been divided by up to 3 (same table, same records). Now I've got a question to specialists : I noticed that performance is even greater on page reload (as fast as just 2/100s). It seems the results are cached somewhere. Let's assume that User1 connects to the page containing the php code that runs the query against the database. If a few seconds later User2 connects to the same page, thus running the same query, will User2 benefit from the results having been cached ? Thanks. BTW:I tried the "GROUP BY field1, field2" suggestion, but unfortunately without noticeable effects.