Re: Re: I need to tell what I pulled from SQL

I was just going to jump in and suggest $sth->rows, but now your comment has given me pause. Can you say more about this method's "unreliability"?

Thanks,

BCE
--Your punctuation skills are insufficient!

Comment on Re: Re: I need to tell what I pulled from SQL Download Code

Replies are listed 'Best First'.
Re: Re: Re: I need to tell what I pulled from SQL by ichimunki (Priest) on Jul 22, 2002 at 19:54 UTC
The problems with this method are documented in 'perldoc DBI'. It is probably more reliable than I would be, but to sum it up, $sth->rows is mostly for do() commands like INSERT, DELETE, etc, so that you know how many rows were affected (as those queries don't really have any other results). I also suspect that DBI functionality, although it is supposed to provide a uniform interface, can vary somewhat based on which type of server is used. There might be a MySQL-specific answer to this question, but it probably wouldn't be very portable-- besides, doing COUNT(*) or simply fetching all the data (since, in this case, only a single row seems to be expected), is just going to be quicker than any other solution.	[reply]

Replies are listed 'Best First'.

Re: Re: Re: I need to tell what I pulled from SQL
by ichimunki (Priest) on Jul 22, 2002 at 19:54 UTC

The problems with this method are documented in 'perldoc DBI'. It is probably more reliable than I would be, but to sum it up, $sth->rows is mostly for do() commands like INSERT, DELETE, etc, so that you know how many rows were affected (as those queries don't really have any other results). I also suspect that DBI functionality, although it is supposed to provide a uniform interface, can vary somewhat based on which type of server is used. There might be a MySQL-specific answer to this question, but it probably wouldn't be very portable-- besides, doing COUNT(*) or simply fetching all the data (since, in this case, only a single row seems to be expected), is just going to be quicker than any other solution.

[reply]