ID: 25460
Updated by: [EMAIL PROTECTED]
Reported By: beckman at purplecow dot com
-Status: Assigned
+Status: Closed
Bug Type: Documentation problem
Operating System: FreeBSD 5.0-RELEASE #0
PHP Version: 4.3.3
Assigned To: georg
New Comment:
There are notes on the mysql_* function pages of deprecated functions
and alternatives to use. The mysql_field_* functions are not
deprecated.
Previous Comments:
------------------------------------------------------------------------
[2003-09-10 16:39:29] beckman at purplecow dot com
Please also add to the documentation an example of what to replace the
now depreciated mysql_list_fields with:
replace: $result = mysql_list_fields($db, $table [, $link])
with: $result = mysql_query("SELECT * FROM ".$db.".".$table." LIMIT
1" [, $link])
Works with mysql_field_* functions (at least it seems to) correctly.
Since mysql_list_fields is now depreciated, you might want to check
your code out soon/now to make sure you don't get screwed when the PHP
team takes mysql_list_fields out of PHP entirely.
------------------------------------------------------------------------
[2003-09-10 15:19:57] beckman at purplecow dot com
changed to Documentation problem (if in fact mysql_field_* functions
are depreciated and not listed as such).
------------------------------------------------------------------------
[2003-09-10 15:09:49] beckman at purplecow dot com
So are mysql_field_* depreciated as well? Should they be marked as
such in the documentation?
You might want to put a nice replacement function in the documentation
for mysql_list_fields (and other depreciated functions) to allow people
to migrate away from mysql_list_fields smoothly and easily without
doing trial and error. I haven't yet figured out how to do this while
continuing using mysql_field_* functions. mysql_query("SHOW FIELDS
FROM db.table") doesn't return the same data in the same format as
mysql_list_fields does.
------------------------------------------------------------------------
[2003-09-10 13:03:01] beckman at purplecow dot com
Whoops. Now that you've marked it depreciated, I withdrawal my bug
report! I'll get phpMyAdmin to stop using it, and thus this bug goes
away. But just for me feeling good, can you not mark it bogus? That
makes me feel like less of a man, and much less of a geek... :-) A
closed would be so much better.
------------------------------------------------------------------------
[2003-09-10 13:00:46] beckman at purplecow dot com
If your supposition is correct (phpMyAdmin is broken), then why would
mysql_list_fields("crt", "assignments") with a currently valid open
link to the database attempt to use the table mysql.assignments? Even
if you give it a link, it uses the mysql database to find the table.
While I'm not a C/C++ programmer, I read the code for that function. I
noticed that ZEND_FETCH_RESOURCE2 was added in 4.0 beta 3, and wonder
if THAT function is somehow causing this obscure occurence of this bug.
Why do I think it is a bug? Because mysql_list_fields DOES work as
advertised in the code I could come up with. HOWEVER, in that specific
example in phpMyAdmin, it does not. I'm wondering if somehow
ZEND_FETCH_RESOURCE2 is returning the wrong mysql->conn that is being
used to connect to the DB and list the fields from a table.
If any connection to a database can be used to read any DB from that
connection, and just before running mysql_list_fields I can do a "show
fields from crt.assignments" and it works using both a defined
link_resource or leaving it blank (using the currently selected
connection), why would mysql_list_fields("crt", "assignments") fail on
the next line?
I swear it isn't bogus. And if it is, I'll buy you a beer or something
and hang my head in shame.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/25460
--
Edit this bug report at http://bugs.php.net/?id=25460&edit=1
