Ошибка odbc sqlstate hy000 номер ошибки 104

10.06.11 — 11:48

Собственно, интересует вопрос кто-нибудь подключался?

У меня подключиться получилось. Но запрос не выполняется:

ошибка при выполнении запроса

по причине:

Ошибка ODBC. SQLSTATE: HY000

Номер ошибки: -104

Описание: [ODBC Firebird Driver][Firebird]Dynamic SQL Error

SQL error code = -104

Token unknown — line 1, column 12

22″. Подскажите куда копать?

1 — 10.06.11 — 12:39

ни у кого не возникало подобных ошибок?

2 — 10.06.11 — 12:40

скуль.ру

3 — 10.06.11 — 12:40

4 — 10.06.11 — 12:41

(0) судя по ошибке — как раз нормально подключиться и не получилось.

Ругается на драйвер ODBC — вроде как не подходящий.

Как хоть подключались-то??

5 — 10.06.11 — 12:41

(4) где ты ругань на драйвер видишь?

6 — 10.06.11 — 12:43

(5) вижу, что ошибку вызывает драйвер подключения.

7 — 10.06.11 — 12:48

подключается нормально. Выводит таблицы. Выбираю нужные мне.

Ругается в режиме «Предприятия». Причем через «Управление внешними источниками» подключение происходит. А при открытии таблицы вываливается ошибка(0).

(3) Перевести я и сам смог. Текст запроса я не вижу.

8 — 10.06.11 — 12:53

Токен не распознался…

А здесь все форумы завалены, как лихо 1С подключается напрямую ко всем SQL-ям и прочим Файрбердам и хавает оттуда любые данные в любых количествах невзирая на различные структуры таблиц хранения и типы самих данных…

Хотя провозившись с этим «лихо подключается» перешли на промежуточную выгрузку в xls и оттуда — спокойно в 1С.

Так что поспрошайте «лихачей» ))

9 — 10.06.11 — 12:54

+(8) *на одном из предприятий перешли на промежуточную выгрузку в xls

10 — 10.06.11 — 12:54

11 — 10.06.11 — 12:54

(7) Вот и мы не видим. А ты его покажи..

12 — 10.06.11 — 12:57

(10) да-да, слышу такое с начала выпуска 8.0, а беспонтовые «подключатели» упорно портят статистику лихих подключений, tycvjnzh на выпуск 8.2 уже ))

13 — 10.06.11 — 12:57

*несмотря

14 — 10.06.11 — 13:16

(11) каким образом?

15 — 10.06.11 — 13:20

(12) у меня с 77 и до сих пор всё нормально подключается. У остальных руки.

(14) А я вижу твою программу?

16 — 10.06.11 — 13:40

(8) Угу, мы уже давно поняли, что 1С настолько плоха, что даже выход из ветвления не позволяет сделать.

17 — 10.06.11 — 14:12

(0) Запрос то покажешь?

18 — 10.06.11 — 14:28

платформа сама генерирует запрос

19 — 10.06.11 — 14:33

(18) Телепатически?

20 — 10.06.11 — 14:36

использую внешние источники данных. Платформа  8.2.14.460.

в конфигураторе я указываю с каких таблиц,какие поля брать.

21 — 10.06.11 — 14:39

(0) зачем вам эта бд, позвольте узнать?

22 — 10.06.11 — 14:40

(16) мало того, и вы будете шокированы, — платформа 1С не отличает объекта Номенклатуры от объекта ТабличнаяЧасть!

(уже вижу заголовки интернетов: «1С-ники шокированы! Они не знали всей правды!»

23 — 10.06.11 — 14:43

(21) это важно? к примеру получать данные о продажах. Просто в новой платформе появился интересный механизм — хочу посмотреть как он работает. Пока понимаю, что не очень

24 — 10.06.11 — 14:45

(23) не самая гибкая база, для боевого использования не пойдет, имхо. используйте EXPRESS на крайняк…

25 — 10.06.11 — 15:08

(24) к сожалению не могу

по поводу ошибки: все таки дело в ODBC драйвере. Поставил

Database Browse. Там есть возможность подключаться напрямую к БД и через ODBC. Через ODBC ошибка «Invalid stringlist index 10». А напрямую всё нормально. буду копать дальше

26 — 10.06.11 — 15:11

(20) Ну, там же все равно формируется какой-то запрос на языке запросов 1С. Вот на него бы взглянуть. Есть вероятность, что там, скажем, используется функциональность, не поддерживаемая Фаербирдовским диалектом SQL.

27 — 10.06.11 — 15:26

28 — 10.06.11 — 15:27

(26) если бы да кабы — то 1С была бы самой лучшей платформой на свете ))

У меня вопрос «там же все равно формируется какой-то запрос» возникает всегда, когда получаю данные в 1С. А ответа нет уже много-много лет.

(25) т.е. вопрос решился правильным подходом, а не танцами 1С-ников с бубном? ))

29 — 10.06.11 — 15:27

(27)… или не решился? ))

30 — 10.06.11 — 15:33

неа не решился. Данные я так и не смог получить — буду думать дальше (

31 — 10.06.11 — 15:49

(27) Ну, значит недопилила 1С внешние источники пока. Пользуйся ADODB по старинке.

32 — 10.06.11 — 15:54

(31)через ADODB и работает :). Просто хотелось скорость работы посмотреть )

33 — 10.06.11 — 16:00

(32) А почему скорость работы отличаться должна?

34 — 10.06.11 — 16:52

Ну через внешние источники все делает платформа. И я могу в запросе связать с данными 1с базы. А через ADO я получаю ТЗ.

35 — 10.06.11 — 17:20

36 — 10.06.11 — 17:41

Спасибо! Стоит релиз 2.1. Попробую обновить до 2.5

37 — 10.06.11 — 17:48

(35) >>Т.к. тут запрос генерируется платформой, то ты его не допилишь

— а тру-1Сники против.

(36) в FireBird много ошибок в этих релизах (бесплатный все-таки), всегда желательно ставить последнюю версию.

Странно, что вы на 2.1 не познакомились с переполнением файла базы. Хотя, может база маленькая…

38 — 10.06.11 — 17:58

200 мегабайт

Давно бы уже руками через ADO запрос написал…

PC running slow?

Improve the speed of your computer today by downloading this software — it will fix your PC problems.

If you receive an invalid error code precision for the microsoft odbc sql hy104 driver, today’s user guide is here to help you.

I have another stored procedure with an input parameter related to varchar (max) and we add this parameter according to the column type of the varchar (max) table (for example, this particular set of lengths is set to -1).
I am using ODBC because we are configured to use it (dsn is a legacy application).

  (fetch_wchar_as_char = true, prefer_unicode = true, read_buffer_size = megabytes (1000), parameters_sets_to_buffer = 200000, large_decimals_as_64_bit_types = true, varchar_max_character_limit = 8000, limit_varchar_results_to_max = true, force_extra_capacity_for_unicode = true) 

  (fetch_wchar_as_char = true, prefer_unicode = true, read_buffer_size = megabytes (1000), large_decimals_as_64_bit_types = true, parameters_sets_to_buffer = 200000, varchar_max_character_limit = 8000, limit_varchar_results_to_max = true, force_extra_capacity_for_unicode = true) 

I have a stored procedure with an input parameter of varchar(max) and we’re inserting this parameter into a table column of type varchar(max) (e.g. the length is set to -1).
I’m using ODBC because we’re configured to use DSN (it’s a legacy app).

My OdbcParameter is specified as being OdbcType.VarChar.

It’s called with ExecuteNonQuery and when the data is exactly 8000 characters it throws the following exception:

InnerException: Message: ERROR [HY104] [Microsoft][ODBC SQL Server Driver]Invalid precision value
StackTrace: at System.Data.Odbc.OdbcConnection.HandleError(OdbcHandle hrHandle, RetCode retcode)
at System.Data.Odbc.OdbcParameter.Bind(OdbcStatementHandle hstmt, OdbcCommand command, Int16 ordinal, CNativeBuffer parameterBuffer, Boolean allowReentrance)
at System.Data.Odbc.OdbcParameterCollection.Bind(OdbcCommand command, CMDWrapper cmdWrapper, CNativeBuffer parameterBuffer)
at System.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method, Boolean needReader, Object[] methodArguments, SQL_API odbcApiMethod)
at System.Data.Odbc.OdbcCommand.ExecuteReaderObject(CommandBehavior behavior, String method, Boolean needReader)
at System.Data.Odbc.OdbcCommand.ExecuteNonQuery()

I am unable to recreate this locally (the error is happening in our production system, so I’m unable to run manual tests there).

While investigating the code I noticed that when we create the OdbcParameter, we’re not setting the Size parameter.

I’m trying to work out how to stop the errors. So far my ideas are:

1. Specify the size when we create the OdbcParameter;
2. If the length is exactly 8000, append a space to the end (it’s XML so when it’s read back out it will be parsed into a XDocument so I thing an appended space won’t make any difference);
3. Maybe try and use a SqlConnection instead of an OdbcConnection and see if the problem goes away.

But because I can’t recreate the error, this is all a stab in the dark.
What could be the actual reason for the error, and what would be the best way of fixing it? I know there’s some sort of change of datapage or something for varchar over 8000 in length but I can’t find anything concrete that’s related to ODBC.

PHP 8.0 Yii2 2.40
When use Firebird PROCEDURE i have the same error:
SQLSTATE[HY000]: General error: -104 Dynamic SQL Error SQL error code = -104 Unexpected end of command — line 1

Did you test yii2-firebird + PHP8?

oh
if name param is witch «_» there error
eg.: :stud_id
When change to: :studid work ok, so:

Yii::$app->db->createCommand(
«select wynik from cz_dajzaleglosc(:stud_id, :data_od, :data_do, 2)»,
[
«stud_id» => 56286, «data_od» => «$data_od», «data_do» => «$data_do»
]
)->queryOne();

• give error:
  SQLSTATE[HY000]: General error: -104 Dynamic SQL Error SQL error code = -104 Token unknown — line 1, column 36 _id
  Failed to prepare SQL: select wynik from cz_dajzaleglosc(:stud_id, :dataod, :datado, 2)

CODE:
Yii::$app->db->createCommand(
«select wynik from cz_dajzaleglosc(:studid, :dataod, :datado, 2)»,
[
«studid» => 56286, «dataod» => «$data_od», «datado» => «$data_do»
]
)->queryOne();
Work ok!