Если какие-то скрытые грабли при использовании байндинг к рекордсет для MySQL?
Проблема в том, что для совершенно вменяемых вызовов хранимых процедур MySQL случается экзепшн-ы. Постоянно! ODBC лог (на клиенте) пишет, что соединение с сервером потеряно. В тоже время, error и qury лог на mysql пишет, что клиент получил ошибку чтения данных и сервер сделал аборт соединению. com_error же пишит в экзепшн обычные для M$ просто невменяемые вещи, типа нет ресурсов.
Интересно, что если заменить вызов хранимых процедур на текст соответствующих запросов, то до какого-то момента работает. Особено плохо тем процедурам, где в теле запросов находятся union, или подзапросы. Может не в IADORecordBinding дело?
ПС. Курсоры - серверные, таймауты по умолчанию. В принципе, хотя запросы и тяжёлые в процедурах, но время исполнения (в SQL browser) не более 300 ms.
ППС. Помогите, пожалуйста мыслями.
Похоже MySQL не поддерживает серверные курсоры ADO. Даже...15.02.07 04:13 Автор: void <Grebnev Valery> Статус: Elderman
> Если какие-то скрытые грабли при использовании байндинг к > рекордсет для MySQL? > Проблема в том, что для совершенно вменяемых вызовов > хранимых процедур MySQL случается экзепшн-ы. Постоянно! > ODBC лог (на клиенте) пишет, что соединение с сервером > потеряно. В тоже время, error и qury лог на mysql пишет, > что клиент получил ошибку чтения данных и сервер сделал > аборт соединению. com_error же пишит в экзепшн обычные для > M$ просто невменяемые вещи, типа нет ресурсов. > > Интересно, что если заменить вызов хранимых процедур на > текст соответствующих запросов, то до какого-то момента > работает. Особено плохо тем процедурам, где в теле запросов > находятся union, или подзапросы. Может не в > IADORecordBinding дело? > > ПС. Курсоры - серверные, таймауты по умолчанию. В принципе, > хотя запросы и тяжёлые в процедурах, но время исполнения (в > SQL browser) не более 300 ms. > > ППС. Помогите, пожалуйста мыслями. Похоже MySQL не поддерживает серверные курсоры ADO. Даже если явно установить для _ConnectionPtr курсор adUseServer (что честно наследует _CommandPtr или _RecordsetPtr), то в дампе TCP/MySQL protocol видно, что MySQL передаёт клиенту весь набор данных, запрошенный или запросом или хранимой процедурой.
Оказалось также, что проблема с потерей соединения характерна для тех хранимых процедур, которые вызываются в цикле на клиенте. Такое впечатление, что это баг сервера MySQL, а не клиентской части. Интересно и то, что для ADO.NET 1.0.7 connector для MySQL аналогичных проблем не наблюдается пока.
Дрова для клиентского ODBC свежие? Попробуй поставить свежие дрова...13.02.07 06:46 Автор: HandleX <Александр М.> Статус: The Elderman
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
