Re: stable driver for multithreaded environment (IIS 5.X)
От | Hiroshi Inoue |
---|---|
Тема | Re: stable driver for multithreaded environment (IIS 5.X) |
Дата | |
Msg-id | 3FDD8B7A.34879C61@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: stable driver for multithreaded environment (IIS 5.X) ("Markus Donath" <md-postgres-donath@netapps.de>) |
Ответы |
Bug correction
|
Список | pgsql-odbc |
Markus Donath wrote: > > Hello, > > thank you for the new version (07.03.0205). > i've tested the version for a few days now with the following results: > > 1. The "corrupted data under stress" problem (up to 07.03.0204) is fixed > 2. Threads are no longer blocked by the "pure virtual function call" error > message box > > But the 07.03.0205-Version introduces new bugs: > > 1. When using updateable recordsets in a database call (no matter if allowed > in the dsn-settings or not), the odbc-driver becomes unusable after a few > statements, and > error-statements ("unknown error") are returned by the database driver. > 2. We use components to cache some data. When i call these components in the > following manner: > comp1.init(connectionstring) > comp2.init(connectionstring) > the second call fails with the new driver. When i vary the connection-string > a bit for the second > call (e.g. by adding something like ";foo=222") , everything works fine. > This lets me think that there might be a problem with connection pooling. > Even when connection pooling and updateable cursors are disabled (by > DSN-Settings), these errors occur. > > Note: these components do not share any database related resources. > For every call made in the entire application a seperate connection is > opened, a call is beeing made and the connection is closed as soon as > possible (this is how to make connection pooling work with windows). > > All in all, this Version is even less stable then 07.03.0204 although some > problems were fixed. > > @Hiroshi Inoue: Are you interested in the odbc-driver-logs ? Yes. Please send me the logs. regards, Hiroshi Inoue
В списке pgsql-odbc по дате отправления: