Баг проявляет себя, когда в параметрах соединения клиента включены криптография и сжатие пакета. Выявляется на запросах, возвращающих большое кол-во записей (у меня было 6000) и большом размере записи (у меня был 1 кб). Всю голову сломал, пока чисто случайно это обнаружил, выявлено было на ODBC драйвере, приложение работает на PB9. При получении набора данных сервер дисконнетит сессию с SQLCode=-308, что и возвращает ODBC клиенту. Если один из этих параметров отключить, то все работает нормально. Так же все работает нормально, если запрос возвращает 1000 записей. Будет время, потом постараюсь воспроизвести этот баг и выложить его на sybase.

P.S. Побороть баг удалось только после 3 часов офигевания, какого спрашивается приложение, запущенное из под PB, работает нормально на этом запросе, а откомпиленное валится, причем с другой БД работает нормально. На предыдущих от 3249 патчах эффект такой же.

Гм, видимо все таки это баг именно в EBF 3249 - DBBACKUP стал отваливатся при копировании страниц, поставил в -c опцию COMPRESS=NO, стало нормально работать, раньше утилита нормально работала. Причем коннект обрывается на бакупах к серверу, у которого принудительно в параметрах включены шифрование и компрессия протоколов.

Сляпал батник, который воспроизводит этот баг на организации бакупа через DBBACKUP. Просьба, если есть возможность, проверьте его на своих серверах, чтобы я при его выкладывании на Sybase мог точно отписать, принадлежит ли он только 3249 или же имеет более ранние корни. Запустите батник, он создаст чистую БД, запустит на нее сервер с включенными сжатием и криптографией протокола, добавит записей для обьему, так как баг плавающий и на малых БД не проявляется и через DBBACKUP в подпапку BACKUP попытается сделать резервное копирование этой БД, в 90% случаев оканчивается неудачей, проверили на билдах 9-ки 3228 и 3249.

P.S. Файлики потом не забыть стереть. Ложить батник лучше куда нибудь в temp и запускать из текущей папки, чтобы гарантировано файлы БД куда нибудь не туда не создались :)

МарсельASA 9.0.2.3249
10 из 10 BACKUP OK
;)
Небось машина быстрая :) Попробуйте увеличить вставляемые записи. У меня пока я не увеличил, бакуп тоже отрабатывал или не срабатывал один раз из трех. То то и печально - отошлю им, а они 10 из 10 получат ок. А у меня клиент стабильно получая 6000 записей валится, причем потом после реконнекта нормально работает :(

Тогда я ничего не понимаю :( Бакуп отваливается именно по tcpip для encription и compress после копирования части страниц с первого раза. Проверено на 3 серверах. Отключал и антивирус и файрволл для чистоты эксперимента. Основное у нас отличие - это у меня P4 с 2 логическими процами, да памяти и винта больше. ОС - WinXP 2 пак.

Проверял на домашней машине и 3 серверах на работе. В итоге 4 машины показывают один и тот же результат. ОС - XP/2003, EBF 3228 и 3249, на всех бакуп обламывается с первого раза. На каких то машинах стоит Антивирус и Файрволл, на каких то нет. Подожду, может кто нибудь сможет воспроизвести баг, прежде чем высылать им.

Ну у меня территориально дом и работа далеко находятся друг от друга, и сети разные. Мда - видно я обладатель эксклюзивного бага под ASCRUS-а :)

Ну попробую им выложить, посмотрим, удастся ли тестерам iAnywhere у себя вопроизвести этот баг ;)

Ggg_oldНа машине Win2000AS Eng+SP4, MB intel 845, cel 1.7, 256ram, hdd ide отработало нормально. Железо не очень, все самое дешевое.
Интересно, у кого не отработало, какие матеря и процы стоят? Нет ли связи с процами не от интел? Пока выходит, что на атлоне не отработало, на трех интелах -ок.
Связи нет - дома у меня Атлон, на работе рабочие машины и сервера - Intel. Так же нет связи с версией Windows, потому как вышибало на 2000/XP/2003. Так же скорее всего нет связи с установленным другим ПО - баг выявлялся на голом 2003+ASA. Плюс самое интересное - баг плавающий, достаточно посмотреть, что при одном и том же выполнении, ошибку можно получить на разном кол-ве скопированных страниц.

Возникло одно предположение, пока в Sybase описывал баг :) У кого нибудь тест нормально отработал на RAM >= 1 гб ?

Спасибо, наверное дальше проверять не стоит. Я уже и не знаю, что может быть общего у всех, у кого бакуп отработал неудачно. В Sybase тоже начали тестировать и естественно по закону подлости пока не могут выловить:
sybase.com06/02/08 15:40 EST
Josh Savill Cannot reproduce this issue on the following:

1. Intel P4 2.8 GHz (hyper-threading enabled), 1.5 GB RAM, Windows XP, EBF 3249
2. Intel P4 1.6 GHz, 1.0 GB RAM, Windows XP, EBF 3228, 3249
3. Intel P3 996 MHz, 512 MB RAM, Windows XP, EBF 3249

Still testing...
Я даже не знаю, куда дальше копать :( Вот стабильно на работе и дома получаю:
CMDCreate Database ...
Database "Test.db" created succe
Start database with option compr
Create table and inserting 30000
Execution time: 0.265 seconds
Execution time: 9.469 seconds
Execution time: 0.328 seconds
Execution time: 1.579 seconds
Execution time: 0.046 seconds
Execution time: 3.375 seconds
Execution time: 0.422 seconds
Backup database with protocol op
Adaptive Server Anywhere Backup
(16 of 1919 pages, 0% complete)
Connection was terminated
Not connected to a database
Database backup failed
BACKUP FAILED !!!
Stop database ...
Press any key to continue . . .
причем тест не отрабатывает всегда. Сейчас попробую развернуть тест на чистом W2000 Prof + ASA 9.0.2.3249 под виртуальную машину - попробую выяснить, кто же виноват - железо или ПО.

Гм, на виртуальной машине все отработало. Параметры: Нулевой Win2000 Prof, 256 RAM, EBF 3249. Основные отличия от реальной машины, где не отрабатывает - нет файрвола Kerio, антивируса Nod32, .NET Framework.