Ошибка 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 запрос написал…

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.

I’m connecting to an old Unix database via an ODBC driver provided by the database vendor (the Unify Corporation). It’s gving me a few problems, most of which I’m pursuing with the vendor, but I’m hoping I might be able to get some help here for the following problem:-

When I try to Add a paramerised query to a DataTable in the DataSet Designer (using the ‘?’ for positional parameters), I get the following error :-

“ERROR [HY104] [Unify][UnifyClient ODBC Driver]Invalid precision value.”

The error shows on the ‘Wizard Results’ page of the ‘Table Adapter Query Configuration Wizard’,  after I click ‘Next’ on the ‘Choose Methods to Generate’ page.

If I click ‘Finish’ here it does generate the command, but gives the HY104 error at runtime.

This only happens when the parameter refers to a STRING field.

I can create paramterised commands in C#, add parameters and run the query properly.

I’ve stripped down the generated code from the designer.cs, and the problem seems to be that the generated code for the parameter creation (see below) defaults the ‘size’ to 1024. If I reduce this manually (to a value below 511) the command works.

new global:ystem.Data.Odbc.OdbcParameter(«supplier», global:ystem.Data.Odbc.OdbcParameter(«supplier», global:ystem.Data.Odbc.OdbcType.VarChar, 1024, global:ystem.Data.ParameterDirection.Input, ((byte)(0)), ((byte)(0)), «supplier», global:ystem.Data.ParameterDirection.Input, ((byte)(0)), ((byte)(0)), «supplier», global:ystem.Data.DataRowVersion.Current, false, null))

I think 512 is the maximum size of a STRING field in this database.

Changing OdbcType.VarChar to OdbcType.Char didn’t help.

The DataSet designer reports that the «supplier» column type is System.String, with MaxLength 12.

Is there any way I can get at the default value in the designer, or is there anything the vendor can do in their ODBC driver ?

Interstingly, If I use Query Builder during the Add Query dialog, I can set a filter «= ?» on the supplier column and Execute the command, and it prompts me properly for the parameter value and displays the correct result. The query it leaves behind still gives the HY104 error later on in the Wizard Results page

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)