Re: AW: AW: [firebird-support] Simply bad, new is not always better. FB3 and ODBC
From SC FB 2.5.2 to SS FB 3.0, all on Win64, I can confirm 2 things : 1) Post Event on SS 3.0, sometimes works, sometime not. I have an app that use post_event. Sometime I have to restart this app a few times to make post_event works. 2) Stored Procedure/Query I have noticed that SP/Query that runs very slow on SS FB 3.0 has an in clause. (perhaps there are other type of query that could cause this). SS FB 3.0 takes different query plan than SC 2.5.2, it slows because not use index. Regards, Anto
AW: AW: [firebird-support] Simply bad, new is not always better. FB3 and ODBC
Hello Mark, 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. Thanks. Von: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] Gesendet: Donnerstag, 12. Mai 2016 20:15 An: firebird-support@yahoogroups.com Betreff: Re: AW: [firebird-support] Simply bad, new is not always better. FB3 and ODBC On 11-5-2016 16:04, 'Checkmail' <mailto:check_m...@satron.de> check_m...@satron.de [firebird-support] wrote: > 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 -- Mark Rotteveel
Re: AW: [firebird-support] Simply bad, new is not always better. FB3 and ODBC
On 11-5-2016 16:04, 'Checkmail' check_m...@satron.de [firebird-support] wrote: > 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 -- Mark Rotteveel
AW: AW: [firebird-support] Simply bad, new is not always better. FB3 and ODBC
Hello Mark, for some firebird-problems – yes, one of them is fixed. About odbc I got no reaction. We are using some stored procedures and tables, I thought, it is possible that fb 3 works every time correct how fb 2.1 and my tests without many clients ends great.. Von: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] Gesendet: Donnerstag, 12. Mai 2016 09:21 An: firebird-support@yahoogroups.com Betreff: Re: AW: [firebird-support] Simply bad, new is not always better. FB3 and ODBC On 2016-05-12 7:37, 'Checkmail' <mailto:check_m...@satron.de> check_m...@satron.de [firebird-support] wrote: > Hello again, > > the most funkctionality are very simply, just tables who linked to > msaccess. > I thought that firebird in every version can do this without any > problems - > how I said is this not in every case true. Also the stored procedures > - > simplel sql - can do something and should work in fb 3 too. But the > main > problem is the odbc driver, the old works not perfect again and the > new has > performance- and refresh-problems. Have you already created tickets for these problems with in-depth description of the problem and the steps necessary to reproduce them? Mark
Re: AW: [firebird-support] Simply bad, new is not always better. FB3 and ODBC
On 2016-05-12 7:37, 'Checkmail' check_m...@satron.de [firebird-support] wrote: > Hello again, > > the most funkctionality are very simply, just tables who linked to > msaccess. > I thought that firebird in every version can do this without any > problems - > how I said is this not in every case true. Also the stored procedures > - > simplel sql - can do something and should work in fb 3 too. But the > main > problem is the odbc driver, the old works not perfect again and the > new has > performance- and refresh-problems. Have you already created tickets for these problems with in-depth description of the problem and the steps necessary to reproduce them? Mark
AW: [firebird-support] Simply bad, new is not always better. FB3 and ODBC
Hello again, the most funkctionality are very simply, just tables who linked to msaccess. I thought that firebird in every version can do this without any problems - how I said is this not in every case true. Also the stored procedures - simplel sql - can do something and should work in fb 3 too. But the main problem is the odbc driver, the old works not perfect again and the new has performance- and refresh-problems. -Ursprüngliche Nachricht- Von: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] Gesendet: Mittwoch, 11. Mai 2016 00:35 An: firebird-support@yahoogroups.com Betreff: Re: [firebird-support] Simply bad, new is not always better. FB3 and ODBC Hello 'Checkmail', Wednesday, May 11, 2016, 2:03:37 AM, you wrote: > We had FB 2.5 CS before our migration to fb 3 SS. After this, the > Frontend (MS-ACCESS) calls a stored procedure and sometimes the > odbc-driver does not wait until the procedure finished and writes the > new records. Impossible. The driver does not "write records". It simply processes a DML request and passes that through the API to the server. And no Firebird server can make the results of an operation in a stored procedure available to other transactions until the transaction in which the SP is running commits. So whatever is happening here, it is not what you think it is. > In this case the user must close the > access-formular to get the new data, if he pushed the button again, > there are two new records present. Some other complications I have > posted, two in the tracker. Ummmso you are telling us that you upgraded a production system from Fb 2.5 to Fb 3 without reading the release notes or testing anything. > Not fine, we have now some problems we never had and the customer does > not pad for the solutions. Developer screws up and customer won't pay to fix it. How sad... > Now I have de-installed the firebird odbc 2.0.4 Driver and install the > 2.0.0.150, the problem with the refresh after calling > adodb-stored-procedure we get a little less, but if I connect to the > odbc-tables again (tables are linked) I get: > Odbc firebird driver firebird attempt to reclose a closed cursor #-501 > Without any changes we have now some problems and Im frustrated! First, this is not the right list for your ODBC problems. Subscribe to the firebird-odbc-devel list and try to post a *rational* problem description there. You switched a production system to a new major version of the database server without comprehending what you were doing and without testing whether it was going to work. "Without any changes" is not the operative expression here. > There are no one in this community who uses odbc and firebird 3.0? Ask that question in firebird-odbc-devel. That is where you will find those people who have been testing the driver against Fb 3.0. > All the good features from the firebird 2.1 (we updated to 2.5 with > similar problems), -- using the same upgrade strategy? > where are they? We dont can close our eyes and leave the new > versions, but we would like to work, just work! So - you want to take advantage of new features and new architecture but you don't want to make any effort to understand, test and control the changes? Sounds heavenly to me. ;-) > Also the post_event behaves different than the old firebird, the never > changed mfc (c++) application gets it sometimes, in many cases not. > Only the version of firebird is changed. Post_event was not changed in Firebird 3. Are you sure that your customer's applications are loading the correct version of fbclient.dll? This question is applicable to your other problems, too. > Im stupid or what can I do to solve? Change control - FAIL. "Eine rechtzeitige Stich spart neun Stiche." To appease your unhappy customer, restore the production system to what was working before. [This won't "just work", either, if your customer has already been posting production data into an ODS 12 database!] Read the documentation (Release notes and Quick Start Guide). Then read them again as many times as it takes to understand the new architecture and the other major changes. Set up a test system for Firebird 3 and establish what the issues are for your software **by testing everything**. Don't throw a major upgrade at your customer until you have solved all the issues. Helen ++ Visit http://www.firebirdsql.org and click the Documentation item on the main (top) menu. Try FAQ and other links from the left-side menu there. Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ ++ Yahoo Groups Links
AW: [firebird-support] Simply bad, new is not always better. FB3 and ODBC
Hello Helen, sorry for my phrase in English, I cannot describe the problems very perfect. -Ursprüngliche Nachricht- Von: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] Gesendet: Mittwoch, 11. Mai 2016 00:35 An: firebird-support@yahoogroups.com Betreff: Re: [firebird-support] Simply bad, new is not always better. FB3 and ODBC >mpossible. The driver does not "write records". It simply processes a DML request and passes that through the API to the server. And no Firebird server can make the >results of an operation in a stored procedure available to other transactions until the transaction in which the SP is running commits. So whatever is happening here, it is >not what you think it is. 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. Unfortunately I cannot test everything like in the production environment, the customer can work but I cannot understand why it works in some cases and in the same situation just not. To test this is very complicated. 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. 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. 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 dont 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. Helen, thank you for your support.
