Stream read error mysql

Read SQL files in UTF8

When I open a utf8 file (with BOM) and :

• leave encoding «auto-detection», the application raise error «stream read error».
• I specified encoding «utf8», the application raise error «stream read error».
• I specified encoding «unicode», the application freeze.

When I open a utf8 file (WITHOUT BOM) and :

• leave encoding «auto-detection», work but not «decode» accent/specials characters (Result : «Bol en céramique fleurs» expected : «Bol en céramique fleurs»);
• I specified encoding «utf8», the application raise error «stream read error»;
• I specified encoding «unicode», the application freeze.

N.B. (1) The sql file is an export from mysqldump. N.B. (2) When I import with phpMyAdmin (and specified utf-8 encoding in html form), BOTH (with and without BOM) imports work perfectly. Note : I like so much HeidiSQL that phpMyAdmin except for this probem.

And for suggestion, an option for execute directly the file (not just the big files).

Same problem here.

I’ve got an UTF-8 encoded SQL file to be imported to MySQL database.

On load, it says «stream error» if «auto-detection» or «UTF-8» is chosen. If «ANSI» is chosen on import, the file loads but is definetely scrambled, e.g. German umlauts read «Anschlüße» instead of «Anschlüsse».

I’m using latest version available: 9.3.0.5083

You might want to try «Load SQL file» AND THEN «Run Query» instead of «Run SQL file». It seems to me that there is an issue with «Run SQL file» so it does not properly handle all supported file formats whereas the other method of loading and then running seems to work beautifully for me at least. If nothing else works, you can open the SQL file in your favorite UTF-8 enabled editor, copy it to the clipboard, and then paste it as a SQL query in HeidiSQL. This method also seems to work for me at least.

When loading a file, you should specify the encoding if you know it, as the auto-detection produced some wrong results in the past. I have already increased the examined text portion to 1MB but that does not always seem to do it. So, prefer UTF-8 or whatever over Auto-detect (may fail)

There has been many reports about problems with UTF-8.

I tried with version 9.5 and it was still not possible to import SQL file with UTF8 BOM (0xEF,0xBB,0xBF). When opening the SQL file into Query window, or menu File->Open SQL File (Ctrl-O) then Heidi seems not to recognize the BOM and Query window shows an empty space on the very first character position (like if file starts with Space character). If then try to run the SQL script (F9) Heidi produces an error with popup Message box and procesing is cancelled.

You can reproduce the problem like this:

1. Open Windows Notepad and type whenever SQL you want; for example, «— This is SQL comment».
2. Save file as test.sql when choosing UTF-8 on the Encoding combobox on the botton-right corner of SaveAs window. -> now you have SQL file with UTF-8 BOM;
3. Back on HeidiSQL, press Ctrl+O and open the sql file. It is no matter what encoding you chose in Heidi’s Open window.
4. The Query window shows space before comment
5. Press F9 -> SQL Error (102): Incorrect syntax near ».

I found no workaround to this issue. Regards

The UTF-8 encoding in the file-open dialog refers to «UTF-8 without BOM». You should just store your files without BOM.

Please login to leave a reply, or register at first.

Источник

EReadError (Stream read error) — an error occurred in the application when importing .sql file

I have googled the problem and found this: http://stackoverflow.com/questions/31242480/importing-sql-file-to-heidisql but I’m sure this file has not been used anywhere else. I guess the reason could be the .sql has tables with Chinese and Japanese characters in it? Any idea?

allocated memory : 73.57 MB largest free block : 8181.43 GB executable : heidisql.exe exec. date/time : 2015-12-08 11:16 version : 9.3.0.5024 compiled with : Delphi XE5 madExcept version : 4.0.12 callstack crc : $e27ced9b, $dc4655bf, $dc4655bf exception number : 1 exception class : EReadError exception message : Stream read error.

main thread ($3d04): 005be30d heidisql.exe System.Classes TStream.ReadBuffer 00969349 heidisql.exe helpers 1288 +15 ReadTextfileChunk 00c2430b heidisql.exe Main 3395 +28 TMainForm.RunQueryFile 00c23759 heidisql.exe Main 3329 +65 TMainForm.RunQueryFiles 00c22d21 heidisql.exe Main 3237 +9 TMainForm.actLoadSQLExecute 005da760 heidisql.exe System.Classes TBasicAction.Execute 00665ae3 heidisql.exe Vcl.ActnList TCustomAction.Execute 005da494 heidisql.exe System.Classes TBasicActionLink.Execute 007eb5dc heidisql.exe Vcl.Menus TMenuItem.Click 007edf0f heidisql.exe Vcl.Menus TMenu.DispatchCommand 007f0464 heidisql.exe Vcl.Menus TPopupList.WndProc 007f0365 heidisql.exe Vcl.Menus TPopupList.MainWndProc 005dbd13 heidisql.exe System.Classes StdWndProc 770e98d5 USER32.dll DispatchMessageW 008145ef heidisql.exe Vcl.Forms TApplication.ProcessMessage 00814663 heidisql.exe Vcl.Forms TApplication.HandleMessage 00814b4f heidisql.exe Vcl.Forms TApplication.Run 00c707d7 heidisql.exe heidisql 78 +24 initialization 76fc5a4b kernel32.dll BaseThreadInitThunk

International characters should not be a problem, but others reported that too, so I must say this can be a problem. I only don’t have a solution for that as I’m unsure about the cause of it.

Please login to leave a reply, or register at first.

Источник

Ошибка Stream Read Error

Чтобы отправить ответ, вы должны войти или зарегистрироваться

Сообщения 10

#1 Тема от Dyaka 29 марта 2021 09:58:31

• 
• Dyaka
• Участник
• Неактивен

• На форуме с 29 марта 2021
• Сообщений: 5

Тема: Ошибка Stream Read Error

Добрый день! Не нашел решения проблемы по данному вопросу. При входе в программу и выполнении любого действия у пользователя вылетает ошибка Stream read error. У остальных пользователей все нормально. Переустановка не помогает.

#2 Ответ от Олег Зырянов 29 марта 2021 10:07:56

• 
• Олег Зырянов
• Технический руководитель
• Неактивен

• Откуда: Новосибирск
• На форуме с 10 декабря 2008
• Сообщений: 4,174

Re: Ошибка Stream Read Error

Здравствуйте! Запустите конфигурацию TechnologiCS с ключом /skipreg или удалите вручную *.cfg файлы https://help.technologics.ru/7.9/TCSHelp/_876.htm

Больше всего похожена это. Хотя. Что значит при выполнении любого действия? Программа то работает в итоге?

#3 Ответ от Dyaka 29 марта 2021 10:58:21

• 
• Dyaka
• Участник
• Неактивен

• На форуме с 29 марта 2021
• Сообщений: 5

Re: Ошибка Stream Read Error

Здравствуйте! Запустите конфигурацию TechnologiCS с ключом /skipreg или удалите вручную *.cfg файлы https://help.technologics.ru/7.9/TCSHelp/_876.htm

Больше всего похожена это. Хотя. Что значит при выполнении любого действия? Программа то работает в итоге?

Работает, пользователь логинится, но после каждого действия вылетает данная ошибка. Запуск с ключом и удаление .cfg файлов не помогло

#4 Ответ от Олег Зырянов 29 марта 2021 11:06:08

• 
• Олег Зырянов
• Технический руководитель
• Неактивен

• Откуда: Новосибирск
• На форуме с 10 декабря 2008
• Сообщений: 4,174

Re: Ошибка Stream Read Error

А можно точную версию TechnologiCS , и более подробное описание того что просходит, послеlовательно по шагам.
В идеале чтобы шаги эти повторялись, а не были случайными. То есть делаем — ошибка. Еще раз делаем — та же ошибка. Перезапустили TCS, повторяем -снова ошибка эта.

#5 Ответ от Dyaka 29 марта 2021 11:17:06

• 
• Dyaka
• Участник
• Неактивен

• На форуме с 29 марта 2021
• Сообщений: 5

Re: Ошибка Stream Read Error

А можно точную версию TechnologiCS , и более подробное описание того что просходит, послеlовательно по шагам.
В идеале чтобы шаги эти повторялись, а не были случайными. То есть делаем — ошибка. Еще раз делаем — та же ошибка. Перезапустили TCS, повторяем -снова ошибка эта.

У пользователя версия 5.7.0.0. Я не большой эксперт этой программы, опишу, как могу. Пользователь логинится, программа загружается, пишет о новых сообщениях, закрываем окно, и вылетает окошко с ошибкой Stream read error. Пользователь его закрывает, делает любой отчет, макрос, ошибка снова вылетает, но действие выполняется. В целом, все работает, просто после каждого действия пользователя с момента входа вылетает окошко с ошибкой.

Источник

HeidiSQL stalls while reading large UTF-8 MYSQL file after repeated «End of file block was cut within some multibyte character, at position xyz» #354

Steps to reproduce this issue

1. create new/empty database X
2. select database X
3. select File/Run SQL File (File/Load SQL file will produce «Stream read error»
4. Encoding = UTF-8, Files of type = All files (.)
5. select large MYSQL file created during a Drupal 7 backup
6. watch progress bar until HeidiSQL stalls at 20MiB/296MiB, 219’733 rows
7. cancel job to return to HeidiSQL

Note: Notepad++ or Sublime open the MYSQL-file without a problem and render the contained multibyte characters (e.g. arabic, chinese, french accents, . ) correctly.

Current behavior

HeidiSQL seems to fail to read (large) MYSQL-files/queries that contain multi-byte characters.

from line 20083 of logfile:

then from line 20093 of logfile the messages repeat with the already mentioned positions from 41’943’040 to 41’943’076, this continues until the last log entries from line 36232 of logfile:

Note: the log file really ends with ‘multibyt’.

Expected behavior

HeidiSQL should be able to read large MYSQL file with UTF-8 encoded multibyte characters without problems.

Possible solution

change strategy to read large files?

Environment

• HeidiSQL version: 9.5.0.5196
• Database system and version: MariaDB 10.3.7
• Operating system: Windows 10 Pro Version 10.0.17134 Build 17134

The text was updated successfully, but these errors were encountered:

Note: MySQL Workbench 8.0 CE connected to the same MariaDB excecuted the same MYSQL file without error.

Are you sure you selected «UTF-8» in the file-open-dialog?

Is there a chance I get that sql file, so I could reproduce this issue?

thanks for the quick response.

I just tried it again to be sure: yes UTF-8 is and was selected.

However, the SQL-File contains sensitive user data . so I cannot send you the (whole) file.
But I am sure the section that causes the trouble with (too many?, an unlucky combination of?) multibyte characters is not sensitive . so if you help me to understand the error log’s «position» I could extract that section and send this part of the query to you. Maybe you can build a test file that pushes this part to a file block boundary and reproduce the undesired behavior.

Or do you see any other way that I can help you narrow down the cause of this problem from my end?

That «position» from the log rows is the byte offset in the file. So, if you extract a portion from

43MB, that should be enough. You can also send it to anse at heidisql.com to keep it a bit more private than here in the tracker.

OK, let me see what I can do . might need to defer it to tomorrow (Sunday) morning, though.

I sent you an email with a test case and log files.

After some research the root cause seems to be that there is non-UTF-8 content in the MySQL file.
It contains LONGBLOBs which have binary data inside.

So my question develops into:

• how to properly import/run such MySQL dumps?
• also: why does the huge MySQL file simply «hang» without a message and the shorter test case throws a «stream read error»?

Ok, I received your mail. And I looked at the .mysql file at first with Notepad++, which says it’s ANSI encoded.

Importing it with HeidiSQL/»Run SQL file» with «UTF-8» selected in the file-open dialog, I get the same crash as you got. When using «ANSI» encoding, it does not crash, and the file seems to be imported correctly, although it may be due to the shortness of the file that it doesn’t have UTF8 characters. Apart from the binary contents, there is just no other critical characters. Are you sure the other content is UTF8 encoded?

good question, I needed to double check.

I have tried to find out what Drupal7 says about their SQL export but did not find anything.

The MySQL script says

that – and the fact that we encode all the texts we import to Drupal in UTF-8 — send me down the UTF-8 path.

When I open the 300MB file in Notepad++ the editor says ANSI for me as well.

But the content does not render correctly, e.g.

When I choose UTF-8 in Notepad++, I see:

… which are the correct Chinese translations for the names of different languages (the final character “话” meaning language).

So at least this content seems to be UTF-8 encoded.
In HEX, Notepad++ gives me the following bytes

richard/utf-8.cgi are the UTF-8 codes you would expect for those characters.

So my conclusion is that this MySQL file also has UTF-8 encoded content. At least some of it.

I am a bit puzzled that the MySQL export from Drupal does render a file that does not have a single encoding … or is this the normal behaviour when we have strings and BLOBs in a database?

And that – during import — an MySQL engine is supposed to read an un-encoded byte stream and choose an encoding based on the data type?

Источник

Ошибка Stream Read Error возникает, когда серверу приложений ЛОЦМАН не достаточно памяти для того, чтобы вернуть все объекты в базу данных.
Если после возникновения ошибки открыть диспетчер задач, то можно увидеть, что скорее всего использованы все доступные ресурсы оперативной и виртуальной памяти. Проблема скорее системная.

Сервер приложений ЛОЦМАН:PLM не ограничивает размер сохраняемого файла.
Существует ограничение ADO/OLEDB (интерфейс MS SQL Server): при работе с файлами требуется

НЕПРЕРЫВНЫЙ БЛОК ПАМЯТИ РАЗМЕРА СООТВЕТСТВУЮЩЕГО ФАЙЛУ

 , который не всегда доступен в системе (даже небольшого размера) — это зависит от степени фрагментированности оперативной памяти.

При использовании Файлового архива это ограничение не действует,
В СУБД Oracle описанная проблема не возникает.

В том случае, если ошибка возникает при наличии файлового архива, в первую очередь необходимо проверить наличие свободного места в архиве. 

Свободное место, доступное для файлового архива указано в ЦУК:
Файловые архивы — [имя файлового архива] справа в информационной области.
Объем памяти, свободный в архиве, и объем памяти доступный на ресурсе где расположен архив не одно и то же!
Так, под архив может быть выделено 50Гб, а на диске свободно 500Гб.
Архив сможет использовать только выделенные ему 50Гб, не зависимо от того, сколько памяти доступно на диске.

Например, в архиве доступно 0,008 Мб, при сохранении файла объемом 30Мб возникает ошибка
Out of memory, Error creating variant or safe array.
Необходимо открыть свойства файлового архива и увеличить максимальный размер архива, в зависимости от потребностей.

Рекомендации по избежанию проблемы:

1. Используйте файловый архив.  
   Перенесите файлы из базы данных в него.  
   Для хранения большого объема файлов лучше использовать файловый архив, а не таблицы базы данных.  
   Подробнее о создании и о работе с файловыми архивами описано в справке на ЦУК/ЛОЦМАН Администратор.
2. Старайтесь чаще сохранять информацию в БД малыми порциями, тогда вероятность появления упомянутой ошибки снизится.
3. Установка дополнительных модулей оперативной памяти на машине, где работает сервер приложений ЛОЦМАН.