После вызова 7z получаю эту ошибку. При создании архива.
Когда ограничиваю к-во файлов - нет ошибки.
Ошибка выдается не сразу. Пауза даже при бездействии, как будто от таймера и пошла ругань.
Проталкиваю долго, но идет на вылет в конце.
Это сообщение знаю по вызову ф-й или процедур с зацикливанием.
Еще при таймере с маленьким интервалом.
А тут - не пойму

Ну так стек посмотри - всё и разъяснится. Зацикливание там, или рекурсия безумная, или на самом деле какие таймеры пачками в стеке вызовов висят
Уж что что, а 7z тут ну явно не при делах.

Да, так и есть!
После 7z стоит
SQLEXEC(goSql.Handle, 'Update archive set zip=?lcZip where recno=?lnRec')
Это запись содержимого заархивированного файла в MediumBlob.
Длина - 36.2МB. А для медиума планка - 16MB
Вот он и дает это!
Главное, отрабатывает и вижу архив. Ну, это понятно.

Неудача в SQLEXEC никак не может сгенерировать ошибку
Allowed DO nesting level exceeded (Error 103)

Что за ошибка вынесена в заголовок темы - я не в курсе. Нет такой в хелпе
Впрочем, SQLEXEC вообще практически никогда никаких ошибок не выкидывает, их можно лишь ручками через AERROR() вынуть и посмотреть.
Возможно как раз на этапе разбора AERROR и пошло что-то не так... Как минимум с текстом ошибки

Опять прав! Сделал longblob, но ошибка осталась...
SQLEXEC(goSql.Handle, 'Update archive set zip=?lcZip where recno=?lnRec')
ошибка идет мимо обработчика ошибок.
При проталкивании это сообщение повторяется, но выскакивают и "Потеряна связь с сервером", несоответствие данных

Я вообще, оставил все до вызова SQLExec - работает норм.
Потом вызываю
lnRec=2
lcZip = filetostr(localpath()+'\Temp4Zip.7z')
SQLEXEC(goSql.Handle, 'Update archive set zip=?lcZip where recno=?lnRec')
где
Temp4Zip.7z - это файл в 38MB. Это не так уж и много...
По Гуглу нашел, что лимит на тип BLOB сам по себе, а что можно передать в БД зависит от объема оперативной памяти...
И как-то не верю в это.

Редактирую это сообщение
Не знаю чем это у меня кончится, но отключил таймеры (а он один) и уже не гавкает.
По-крайней мере, походу, вопрос мой внутренний.
Хотя, какое отношение этот SQLEXE имеет к этому таймеру - я сейчас не понимаю
Там просто ничего нет общего.
Таймер в сети обновляет информацию о пользователях проги и может переслать cmc-ки от одного другому
Таймаут беру



Исправлено 2 раз(а). Последнее : Ydin, 28.03.18 17:34

Саша.
Попробуй blob (Temp4Zip.7z') положить в Мемо поле, и из него уже тяни на сервер. (всё сильно от драйвера зависит)

Код у таймера взял в try/catch - пофиг
Вообще сама запись в поле Blob - 3.6 sec и это мало

PaulWist
Попробуй blob (Temp4Zip.7z') положить в Мемо поле

У меня еще там ничего нет, это я туда пишу.
Т.е. у меня просто переменная (в памяти) и я ее пишу в поле BLOB.
Когда читаю - да, и это я знаю от PaulWist, раньше еще, и это важная штука и спасибо большое!
В Хелпе про general мало по этому вопросу.
Вот мой код, когда читаю

Цитата:

selesql([Zip from Archive where recno={{wTemp.recno}}], 'wTemp')
lcZipFile = LocalPath()+'\ArcZip.zip'
crea curs wTemp1 (Zip M)
INSERT INTO wTemp1 SELECT CAST(Zip as W) FROM wTemp where lnrecno =Recno()

Тут кусок кода по моему Framework'у
Понять можно, хоть это другой язык



Исправлено 1 раз(а). Последнее : Ydin, 28.03.18 18:55

Нашел. Это в обработчике ошибок от Mysql.
Человек уволился, в его коде.

Человек не виноват. Там все нормально.
Виноват

Ydin
SQLEXEC(goSql.Handle, 'Update archive set zip=?lcZip where recno=?lnRec')

Код возврата не смотрел (лоханулся), ведь результат увидел. А он -1!
Connectivity error: [MySQL][ODBC 3.51 Driver][mysqld-5.0.18-nt]MySQL server has gone away
Код ошибки - S1T00.

Т.е. говорит, что связь вылетела. И так каждый раз!
О чем еще подумать?
Это потом он гонит "Allowed DO nesting..."
Может, на какое-то ограничение MYSQL нарвался?
Но, вроде, результат есть. И это поле читается



Исправлено 1 раз(а). Последнее : Ydin, 29.03.18 15:06

Если бы он не был виноват, то обработчик ошибок не циклился бы. А если циклится не обработчик ошибок а вызывающий SQLEXEC код - из-за "необработки" возникшей ошибки - ну тогда виноват тот кто такой код и написал.
SQLEXEC абсолютно не виноват - он корректный. И даже то что ему подсовывают "плохие" параметры - тоже не является проблемой, это нормальная ситуация. Ненормально её НЕ обрабатывать, так чтобы ничего более не ломалось И да, в зависимости от природы возникшей проблемы правильной методой обработки может быть и закрытие приложения, или своего рода "перезапуск" его - как минимум для переподключения к серверу, раз уж он "отвалился".

Игорь, но когда я ему (SQLEXEC) подсовываю 20Кб, то все нормально. 36.2 МБ - дает ошибку.
Так и возвращает -1 и "MySQL server has gone away". Разрыв связи.
И запускаю без обработчика ошибок!

Интересно, кто-нибудь засовывал такой объем в longblob?

P.S. Проверил - до 16Мб - нормально, больше - ошибка.
Но поле longblob!



Исправлено 2 раз(а). Последнее : Ydin, 29.03.18 19:21

Что значит "даёт ошибку" - вот прям на SQLEXEC() у тебя фоксовая error 103 вываливается?
А то что SQLEXEC возвращает -1 это как раз нормально. И то что он разрывает соединение при некоторых типах ошибок (а то и вообще без ошибок - например по таймауту) - это тоже нормально. Просто это нужно обрабатывать. Если соединение "глобальное" - да, это проблема. Проще закрыть прогу и запустить заново. Если соединение локальное - только для этого модуля используется, тогда проще - достаточно вернуться в начало модуля - грубо говоря перезапустить сломавшийся метод/процедуру (конечно же после исправления ситуации приведшей к ошибке).

А как работать с большими блобами - ну это надо изучать документацию и экспериментировать - возможно что надо порциями заливать данные, возможно какие-то волшебные ключики в строке соединения, возможно тупо поменять ODBC драйвер...

Но для начала отдели главную системную проблему (то что банальная ошибка в SQLEXEC абы что абы где в приложении выкидывает), от собственно вопроса записи здорового блоба в базу. Возможно стоит для такой "сомнительной" операции сделать отдельное соединение - если остальная прога тоже с этой же БД работает - лучше пусть сломается 1 функция ПО чем ВСЕ.

Ещё раз повторюсь - возникновение ошибок при работе с сервером (в т.ч. и разрывы соединения) - это нормальная ситуация. Она не должна какие-то невнятные error 103 вызывать, или по другому вводить приложение в нестабильное/нерабочее состояние.

Igor Korolyov
Что значит "даёт ошибку" - вот прям на SQLEXEC() у тебя фоксовая error 103 вываливается?

Нет. После этого все еще работает, но до первого обращения к БД MySql.

Связь обрывается случайным образом, а здесь закономерность.
Что-то приводит к обрыву.



Исправлено 2 раз(а). Последнее : Ydin, 30.03.18 08:34

Какая разница что приводит к обрыву? Код должен быть написан так, чтобы корректно такую ситуацию обработать. Ну никак не error 103 должен "потом" возникнуть!

Код - это одна строка SqlExec. И я ее привел выше

Ещё раз - на этой строке возникает ошибка 103?
Возникает где-то потом, поскольку соединение порвалось - ну так в этом "потом" и написано значит некорректно. Без должной обработки ошибок.

(странные они, плюс таймер, ну отключи таймер, кстати, зачем он? )

Я зауже не говорю. Это следствие.
Меня интересует причина.
Нет уже ни таймера, ничего - один sqlexec
Про 103 забыли



Исправлено 1 раз(а). Последнее : Ydin, 01.04.18 09:49