|Subject||AW: AW: [firebird-support] Simply bad, new is not always better. FB3 and ODBC|
within 2.5 we uses classic server (problematic superservers does’nt use more cores), since 3 we installed the superserver-version (which supports more cores too).
The isolation-level is given by the odbc-driver and should be not the problem. I have actually no idea, sometimes it works very well, then today I got the message “Again I must close the access to get the inserted records”. Not a win-win-situation. Just a stored-procedure-call, not who should firebird take to the border. We had test if the sp takes more time, access waits (fb 2.5). This test we could next week do with 3.0.
I would only more reliability.
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 myThat is the difference between a multi-billion dollar company with
> part to understand everything how firebird works. MSSQL I can install in
> every version, except new functions everything works in a new version like
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 callIt depends. We can't possibly tell from the few details you have provided.
> 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.
> That not all can be perfect have I realized, I have posted some issues how II strongly recommend creating automated tests. It removes the drudgery
> 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.
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. ThisIf it happens with a lot of connections, it sounds more like a race
> 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.
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)?