Chris,
I can't tell you how much time DB_Browser has saved
us. You've created a great set of CGIs that give us
complete control over our database in a fraction of
the time it would have taken me to develop them.
Having said that, I'm experiencing a small problem
trying to search through one of our tables. This is
the rundown:
Setup:
S/W: Solaris 2.7, 64-bit;
Perl: 5.6.0
Database: Oracle 8
DB_Browser: Version 1.40, Date: May 14, 2001
I can get search.cgi to report back all records for
all tables. And for some of the tables, search.cgi
will successfully do a partial match search and return
the results (which rocks!). However, for one table
the search fails when parameters are supplied. The
error string is as follows (I've modified it to
include the SQL statement being executed):
>>>
Can't execute statement: ORA-01410: invalid ROWID (DBD
ERROR: OCIStmtExecute)
Query: select * from stores where (rowid = 'AAAA3
AAQAAAAEHAAA')
<<<
Can you suggest what I might be doing wrong and/or how
I can correct the problem? The table is defined as
follows
Name Null? Type
------------------- ------------
ID NOT NULL NUMBER(11)
NAME NOT NULL VARCHAR2(128)
STOREKEY NOT NULL VARCHAR2(64)
CBURL VARCHAR2(4000)
If I specify "http" (no quotes) as the param for
CBURL, records are returned. If I specify "http:",
error 01410 is returned with a different row id.
Specifying values for any of the first three fields
will generate the 01410 error as well.
If there's any other information I can provide, please
let me know.
You can contact me at matt_weagle@hotmail.com. Thanks
again for your help and keep up the great work.
Logged In: YES
user_id=8993
Matt,
Thanks for your message and your kind words. If you're
interested in supporting the project financially, see how
here:
http://www.summersault.com/software/db_browser/moneystuff/in
dex.html
I appreciate it.
A few questions about your problem:
-Is there really a line break in the "rowid" string of
letters in the SQL statement you pasted in, or is that just
the formatting of the text in the support request?
-What happens if you run the error-causing search, and
then manually execute the SQL statement being run?
-The SQL statement you pasted in is the statement that's
run when one record has been found and it's being pulled up
for editing. Do you have a record of the SQL statement
being executed for the actual search?
If you can answer these, that should get us a little
farther. Thanks for using DB_Browser.
Chris
Logged In: YES
user_id=232063
Chris,
Thanks for the quick reply. I know how frustrating it can
be to support "free" software. Doesn't time count for
anything ;-)
(1) No, the line break is due to the support request
formatting and is not part of the error string.
(2) If I try to execute the command through sqlplus I also
receive the ORA-01410 error.
(3) I don't have a record of the query being generated for
the search itself. I only added extra code in the error()
function to output the query responsible for an error.
Since the actual search doesn't seem to fail, the search
query is never outputted. I might be able to "fake" it
though. Let me get back to you.
Thanks again.
Logged In: YES
user_id=232063
Chris,
I've logged the calls that go through execsql The modified
execsql function is as follows:
#BEGIN
sub execsql {
my ($sql_statement) = @_;
logIt("\nStatement: $sql_statement\n");
my $sth = $dbh->prepare($sql_statement) || &error
('prep_sql', $sql_statement);
logIt("Prepared: $sql_statement\n");
if ($dbh)
{
if (defined($sql_statement))
{
$sth->execute || &error('sql', $sql_statement);
logIt("Executed: $sql_statement\n");
}
else
{
&error('sql', $0);
}
}
else
{
&error('connect');
}
# now that MySQL supports some basic transactions, you
may want to modify this
unless ($MYSQL)
{
$dbh->commit;
logIt("Committed\n");
}
return $sth;
}#END
The output from the failed search (searching stores WHERE
id='1') is as follows:
# BEGIN
Statement: select * from stores where (1 = 0)
Prepared: select * from stores where (1 = 0)
Executed: select * from stores where (1 = 0)
Committed
Statement: select stores.rowid, stores.* from stores where
(ID = 1)
Prepared: select stores.rowid, stores.* from stores where
(ID = 1)
Executed: select stores.rowid, stores.* from stores where
(ID = 1)
Committed
Statement: select count(*) from stores where (ID = 1)
Prepared: select count(*) from stores where (ID = 1)
Executed: select count(*) from stores where (ID = 1)
Committed
Statement: select * from stores where (rowid = 'AAAA3
AAQAAAAEHAAA')
Prepared: select * from stores where (rowid = 'AAAA3
AAQAAAAEHAAA')
# END
Hope this helps and let me know what else I can do. Cheers.
Logged In: YES
user_id=86203
Hi, I'm getting this same error and have noticed that what's
happening is that the ROWID contains a plus sign (+) which
is getting translated to a blank space ( ) at some point,
thus causing the query failure. I'm guessing that the fix
might involved URL-encoding the ROWID at the right place.
Logged In: YES
user_id=86203
Yep, there is a place in the code where rowid's are directly
inserted into a URL. db names, too. URL-encoding them at
this point seems to fix the problem. Here's a patch:
*** search.cgi.orig Tue Dec 2 13:36:21 2003
--- search.cgi Tue Nov 30 16:35:52 2004
***************
*** 69,75 ****
if (($ntuples == 1) && ($edit_enabled)) {
my @tuple = $search_query->fetchrow;
my $oid = shift(@tuple);
! print "Location:
edit.cgi?dbb_action=edit&dbb_db=$db&dbb_oid=$o
} else {
&return_results($search_query, $ntuples);
}
--- 69,80 ----
if (($ntuples == 1) && ($edit_enabled)) {
my @tuple = $search_query->fetchrow;
my $oid = shift(@tuple);
! my $udb = $db;
! $oid =~ s/[^ \w!\$'()*,\-.]/sprintf('%%%02x', ord
$&)/ge;
! $oid =~ s/ /+/g;
! $udb =~ s/[^ \w!\$'()*,\-.]/sprintf('%%%02x', ord
$&)/ge;
! $udb =~ s/ /+/g;
! print "Location:
edit.cgi?dbb_action=edit&dbb_db=$udb&dbb_oid=$oid\n\n
} else {
&return_results($search_query, $ntuples);
}
Logged In: YES
user_id=8993
Classified as bug for addressing in future versions.