Простая ошибка в Perl с использованием dbi

У меня ошибка в моем операторе подготовки

$sqlst = $dbh->prepare('SELECT * FROM starter_trot WHERE UserId = 2345' ) or die "Couldn't prepare statement: " . $dbh->errstr;
$sqlst->execute($userid) or die "Couldn't execute statement: " . $sqlst->errstr;
my @data;
print"hai";
while (@data = $sqlst->fetchrow_array())
{
print "**";
}

оператор выполнения и оператор подготовки точно не завершатся ошибкой.

[ГДЕ UserId = 2345] Это часть, в которой происходит сбой. Когда я запускаю запрос в базе данных, он возвращает значения. Но когда я запускаю запрос через сценарии, он терпит неудачу (но нет проблем с компиляцией или временем выполнения). при подготовке мы должны дать с? (привязать переменные, а не фактические значения?) ~ ~


oracle dbi perl
person user682571    schedule 24.05.2011    source источник
comment
Каково все сообщение об ошибке?   -  person Eric Johnson    schedule 24.05.2011
comment
Попробуйте добавить \n в конец напечатанных строк; возможно, вывод просто буферизуется?   -  person ysth    schedule 24.05.2011
comment
Нет сообщения об ошибке. Я не получаю набор результатов в массиве....   -  person user682571    schedule 24.05.2011
comment
Как вы проверяете, что вы не получаете набор результатов в массиве? Поскольку вы устанавливаете @data для каждой получаемой строки, пустая строка может уничтожить ваш @data?   -  person TLP    schedule 24.05.2011
comment
Что произойдет, если вы (a) измените запрос на SELECT 1234 FROM DUAL, (b) удалите ненужный параметр из execute() и (c) поместите < i>новая строка в конце каждого вызова print?   -  person pilcrow    schedule 24.05.2011
comment
@TLP, что ты имеешь в виду под пустой строкой? Вы имеете в виду строку undefs (NULL)? Что бы не разорвать петлю. Вы имеете в виду конец записей (в данном случае записи не найдены)? Это разорвало бы петлю.   -  person pilcrow    schedule 24.05.2011
comment
@pilcrow Ну, я не уверен в логике здесь, но что-то вроде if (@a = undef) { print @a } все равно установит @a.   -  person TLP    schedule 24.05.2011
comment
Вероятно, это дополнительный параметр для execute, но вы уверены, что подключаетесь к той же базе данных в коде, что и в командной строке?   -  person Schwern    schedule 25.05.2011

Ответы (2)


arrow_upward
3
arrow_downward

используйте strict, используйте предупреждения, а при использовании DBI используйте RaiseError. Вы выполняете с одним значением привязки, когда в вашем операторе SQL нет заполнителей. Конечно, вы должны увидеть сообщение об ошибке в том виде, в каком оно у вас есть (поскольку PrintError используется по умолчанию), но RaiseError проще, чем разбрызгивание «или умри...» повсюду.

person runrig    schedule 24.05.2011

arrow_upward
0
arrow_downward

БД, вероятно, возвращает имя столбца в верхнем регистре. Пытаться:

$sqlst = $dbh->prepare('SELECT * FROM starter_trot WHERE USERID = 2345' ) or        die "Couldn't prepare statement: " . $dbh->errstr;
$sqlst->execute($userid) or die "Couldn't execute statement: " . $sqlst->errstr;

и я уверен, что это будет работать.

person wadesworld    schedule 24.05.2011
comment
Плохо - мне только что пришло в голову, что при доступе к именам столбцов через fetchrow_hash вы должны ссылаться на них в верхнем регистре. - person wadesworld; 24.05.2011
comment
Oracle все равно, пишете ли вы имена столбцов/таблиц в верхнем или нижнем регистре. Если только вы не поставите их в кавычки. - person runrig; 24.05.2011
comment
@runrig - Oracle этого не делает, но DBI делает это при извлечении данных с помощью fetchrow_hash. - person wadesworld; 25.05.2011
comment
Я не вижу fetchrow_hashref в ОП. Ни какой-либо выборки имен столбцов. А верхний/нижний регистр хеш-ключей можно контролировать с помощью атрибута FetchHashKeyName (который, как правило, лучше всегда использовать при выборке хэша). - person runrig; 25.05.2011