Re: BIIIG problem with some of the records
Hi Edward,
I hope I don't annoy you. If so, please tell me.
Not at all - you'll be the first to know! However you/I would be more comfortable if
things were kept on the
list - (a) others might 'jump in' and solve your problem before I find the
time/inspiration, and (b) everyone
with similar problems can learn from you!
Please tell me if there are sentences in my messages, that you have difficulty
understanding/translating - I'm
quite used to working in a multi-lingual situation (but quite confident that I cannot
converse with you as well
as you can with me!)
My first thought is that you have a neat system of encoding the link data
being stored in MySQL.
I assume this is preceded by some sort of 'extract' function which takes
the link out of some HTML page? That
being the case, and particularly if you are using a PREGI to accomplish
the 'extraction', why don't you store
the two components of the HTML link in two separate columns? So a
href=http://www.test.com; test /a could
become www.test.com and test. The disassembly step being part of the
(presumed) existing PREGI and
reassembly afterwards being a snap - seems easier than all those
EREGI_REPLACEs!
Yes, indeed, this was the first thing I thought to, but I can't store them
separately, because they are being part of an large amount of other stuff
and tags (i.e. a HTML content of a web page).
Does this mean that you don't just use MySQL to store a short string, eg the
ahref=http://www.test.com;
test /a you have mentioned to-date, but that this is a small portion of a
chunk/whole page of HTML stored in
the db/tbl?
There is no reason why you cannot store both 'small bits' of the code, and the whole
of the rest of a page,
separately/together/alongside each other - check out how PHP templating systems work!
(that process involves
exactly the same functionality as you have here)
Here is the code for input:
-- cut-
mysql_select_db(falrdb,$con) or die (nu pot);
*
$chtml=eregi_replace('',' \[st]',$chtml);
*
$chtml=eregi_replace('','\[dr] ',$chtml);
*
$ins= INSERT INTO continut (cef) VALUES
'$chtml');$rezins=mysql_db_query(falrdb, $ins, $con);
**
-cut--
Here is the code for output:
---cut--
$q=select * from continut;
$rez=mysql_db_query(falrdb,$q);
**
$zz=mysql_fetch_row($rez);
*
$zz[0]=eregi_replace('\[st]','',$zz[0]);
*
$zz[0]=eregi_replace('\[dr]','',$zz[0]);
*
$zz_fsh=stripslashes($zz[0]);
*
echo $zz[0];
-cut---
Do I observe STRIPSLASHES() but no ADDSLASHES()?
Yes. A friend, more experimented than me told the ADDSLASHES() is not
required if the magic_quotes_gpc are on
Ok, I NEVER use such things - I like to convince myself that I am in charge, and the
computer will do nothing
behind my back/without my explicit instruction (yes, I'm fooling myself, but it's a
'reality' I've grown
comfortable with). So I cannot comment on the effect of combining magic_quotes with a
*SLASHES(). I would be
tempted to remove the STRIPSLASHES() altogether and observe the debug ECHOs closely to
observe any differences.
Next suggestion: what happens if you turn magic_quotes off, and if necessary put a
pair of *SLASHES() back in?
Recommend the addition of a debug ECHO BRchtml=$chtml~; (or
equivalent) at every line where I have marked *.
Recommend the addition of a validation step to assure the MySQL interface
calls where I have marked **.
Done. The result was the same... ECHO is working fine... :)
The last/only ECHO statement examines the reconstituted HTML link BEFORE
the call to STRIPSLASHES() - not the
resultant value!?
Damn!!! 10x. After correcting the problem, there are still links that work
and that don't work, even after printing the correct value!!!
Please post a couple of examples of those that worked, and five or six of those that
failed.
I would also like to see a copy of the debug output (as discussed above) showing one
(or more) running through
these sequences of instructions in the script.
Is cef the first field in continut?
Is the only important field, and is the content. (the other one is the id
(auto_increment field) used for index of the table)
This was not the reason I asked the question - I was keen to ensure that what was
returned from the db by the
SELECT/mysql_db_query() was the cef value and NOT an ID (or something else). Are you
confident that the value
returned is the correct field and a valid/correct value for cef?
I hope that it will be OK for debugging... If not, I'll send you more
Don't hesitate to be 'generous' - the more you show, the better the chance
that we'll spot something out of
place!
Once you have added the above debugging ECHOs, please run the routine and
show what happens with a sample that
works, and then two or three samples that don't.
Re: BIIIG problem with some of the records
Hi Edward,
[I've put this back on the list - others will be able to share their wisdom/you might
not have to wait so long
for me to get around to a reply!]
My first thought is that you have a neat system of encoding the link data being stored
in MySQL.
I assume this is preceded by some sort of 'extract' function which takes the link out
of some HTML page? That
being the case, and particularly if you are using a PREGI to accomplish the
'extraction', why don't you store
the two components of the HTML link in two separate columns? So a
href=http://www.test.com; test /a could
become www.test.com and test. The disassembly step being part of the (presumed)
existing PREGI and
reassembly afterwards being a snap - seems easier than all those EREGI_REPLACEs!
Here is the code for input:
-- cut-
mysql_select_db(falrdb,$con) or die (nu pot);
*
$chtml=eregi_replace('',' \[st]',$chtml);
*
$chtml=eregi_replace('','\[dr] ',$chtml);
*
$ins= INSERT INTO continut (cef) VALUES
'$chtml');$rezins=mysql_db_query(falrdb, $ins, $con);
**
-cut--
Here is the code for output:
---cut--
$q=select * from continut;
$rez=mysql_db_query(falrdb,$q);
**
$zz=mysql_fetch_row($rez);
*
$zz[0]=eregi_replace('\[st]','',$zz[0]);
*
$zz[0]=eregi_replace('\[dr]','',$zz[0]);
*
$zz_fsh=stripslashes($zz[0]);
*
echo $zz[0];
-cut---
Do I observe STRIPSLASHES() but no ADDSLASHES()?
Recommend the addition of a debug ECHO BRchtml=$chtml~; (or equivalent) at every
line where I have marked *.
Recommend the addition of a validation step to assure the MySQL interface calls where
I have marked **.
The last/only ECHO statement examines the reconstituted HTML link BEFORE the call to
STRIPSLASHES() - not the
resultant value!?
Is cef the first field in continut?
I hope that it will be OK for debugging... If not, I'll send you more
Don't hesitate to be 'generous' - the more you show, the better the chance that we'll
spot something out of
place!
Once you have added the above debugging ECHOs, please run the routine and show what
happens with a sample that
works, and then two or three samples that don't.
Regards,
=dn
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
BIIIG problem with some of the records
Hello, I'm using MySQL 3.23.32 and PHP. When an URL is retieved from the database, two things can happen: 1. it's working 2. it's not working and in look like: http://localhost/http://www.test.com/; My big question: WHY using the same DB the URL is well retreived in a page and wrong in another?! Even in the same page I have the good and the bad ones toghether!!! It could be the PHP engine, it's the MySQL daemon, or the Apache Server??? - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
BIIIG problem with some of the records
Hello, I'm using MySQL 3.23.32 and PHP. When an URL is etieved from the database, two things can happen: 1. it's working 2. it's not working and in look like: http://localhost/http://www.test.com/; My big question: WHY using the same DB the URL is well retreived in a page and wrong in another?! Even in the same page I have the good and the bad ones toghether!!! It could be the PHP engine, it's the MySQL daemon, or the Apache Server??? 10x! - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: BIIIG problem with some of the records
Hello Edward, I'm using MySQL 3.23.32 and PHP. When an URL is retieved from the database, two things can happen: 1. it's working 2. it's not working and in look like: http://localhost/http://www.test.com/; My big question: WHY using the same DB the URL is well retreived in a page and wrong in another?! Even in the same page I have the good and the bad ones toghether!!! It could be the PHP engine, it's the MySQL daemon, or the Apache Server??? Please provide more information - the list's crystal ball filter still hasn't been fixed!? What does the actual data look like in the db? Are you sure that the above example is not 'real data'? What does the pertinent part of the PHP code look like? (or parts!) Is that URL the actual code passed to the browser? Have you put some 'debug' ECHOs into the code to track the progress of the URL values as they move from db, through any processing, to the output HTML? The set of three double quotes may indicate a syntax error in the PHP code somewhere! Please advise, =dn - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: BIIIG problem with some of the records
It would help to see either the PHP code or the SQL statement. =S. On Tue, 26 Feb 2002, Edward Ionescu wrote: Hello, I'm using MySQL 3.23.32 and PHP. When an URL is etieved from the database, two things can happen: 1. it's working 2. it's not working and in look like: http://localhost/http://www.test.com/; My big question: WHY using the same DB the URL is well retreived in a page and wrong in another?! Even in the same page I have the good and the bad ones toghether!!! It could be the PHP engine, it's the MySQL daemon, or the Apache Server??? 10x! - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
