Subject Re: AW: [firebird-support] Simply bad, new is not always better. FB3 and ODBC
Author Mark Rotteveel
On 11-5-2016 16:04, 'Checkmail' check_mail@... [firebird-support]
> I have already tested the new version of firebird, but I think it is not my
> part to understand everything how firebird works. MSSQL I can install in
> every version, except new functions everything works in a new version like
> before.

That is the difference between a multi-billion dollar company with
dedicated teams of testers, and a small, underfunded, open source
project. Welcome to the open-source world, where the community is
expected to lift part of that burden.

And yes, you can have some expectation of quality, but all too often
people only start to really test when the first official release is done.

> Yes, I have posted it in the odbc dev, but I got no answer. If MSACCESS call
> a stored procedure (which inserts records) and Access waits until this
> process ends, it can refresh and get the new data. But why works it in the
> most cases and sometimes not? Wrong thinking of me? I hope I can expect that
> firebird fundamental works like before, or isn't it? The new architecture
> should not have an effect of a stored procedure who inserts some records.

It depends. We can't possibly tell from the few details you have provided.

> That not all can be perfect have I realized, I have posted some issues how I
> see after migrating. Hundreds of tables and stored procedures I cannot test
> again and again, if there some more clients connected it should work how one
> client. The odbc-driver is the critical component, the old version works
> nearly perfect but with fb3 I can determine some problems. The new one works
> not good, the performance is bad (slowly compared with the old one) and the
> refresh works not in every case.

I strongly recommend creating automated tests. It removes the drudgery
from testing, and it is great to flush out regressions.

> Thank you Thomas for the link, the post_event sounds like a bug in fb3. This
> can happen, but I cannot expect the unexpected and believe in firebird. You
> all make a great job, but I only will develop the database, not be a tester
> or develop and understand the whole firebird-system. A table should work
> like a table and the odbc-connection should not work worse like before. We
> uses the newest version of MSAccess and as it appears, the very old gemini
> odbc driver works better than the newest of firebird-development.
> How can I post a "rational" problem when it is random one? I test it, in my
> freetime too, will make a great job, but how can I win when even the simply
> things don’t work again? All other components (mfc, c++) works, expect the
> post_event. Yes, we are using the fbclient.dll from the fb3.0.
> I already read the documentation, but once more, It works mostly, but there
> are some things how works unreliable. And I have brought a helping hand -
> fb-support. The actual complications could I not see by testing without the
> real environment by using a few connections. Mostly it works good, but how I
> said, not reliable.

If it happens with a lot of connections, it sounds more like a race
condition (either in Firebird or in your software), or possibly wrong
use of transaction isolation levels.

What Firebird model did you use with 2.5, and what model do you use now
(SuperServer, SuperClassic or Classic)?

Mark Rotteveel