[Firebird-devel] [FB-Tracker] Created: (CORE-6468) Wire compression causes sporadic "Error reading data from the connection." errors.
Wire compression causes sporadic "Error reading data from the connection." errors. -- Key: CORE-6468 URL: http://tracker.firebirdsql.org/browse/CORE-6468 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0.7 Environment: Firebird 3.0.7, Windows 10 Reporter: michalk1 Attachments: TestCase.zip I came across this problem infrequently since first FB 3 versions. Now I finally found that it is related to WireCompression and was able to create a relatively reproducible test case. It consists of a repeated run of a long sql statement, with commits between them. It is easier to spot the error when the test is run concurrently from more consoles. Steps to reproduce: 1) Make a copy of a employee.fdb (or any other database) database, for example to "C:\Tmp\employee.fdb". 2) Modify firebird.conf to enable client wire compression (WireCompression = true). 3) Unzip test case script files (TestMain.sql and TestCmd.sql), say to "C:\Tmp\". TestCmd.sql is the command itself followed by a commit, TestMain.sql is there just to call it repeatedly. 3) Run several command line consoles (two should be enough), and in each of them, execute the sql script in isql: isql -user SYSDBA -password masterkey localhost:C:\Tmp\employee.fdb -i "C:\Tmp\TestMain.sql" 4) Sooner or later in some of the consoles (you may run the script repeatedly of from more consoles) you should spot the errors. The first one is always "Error reading data from the connection.". Following "Error writing data from the connection." are just consequence of the already dropped connection. Clues: - Disabling wire compression results in no errors at all. - Short sql statement are less likely to be affected, may be there is even a threshold under which the error doesn't occur. Contents of the long sql statement probably doesn't matter, just it's length. - When the error arises, other connections continue to run (at least for some time), which means that the problem is not caused by a server crash. It is just the single connection that drops out. - So far i couldn't reproduce the problem against Linux server, it may be Windows specific. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6348) Wire compression causes freezes in FB 3.0.6
Wire compression causes freezes in FB 3.0.6 --- Key: CORE-6348 URL: http://tracker.firebirdsql.org/browse/CORE-6348 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0.6 Environment: Tested on Win 10 and virtual Ubuntu 20.04 (server side) with 64 bit FB 3.0.6, client app at Win 10. Reporter: michalk1 Extracted from CORE-6346, as it is likely an independent issue. Active wire compression causes periodic blocks in FB 3.0.6. I first noticed it when inserting large binary blobs and executing long ddl statements, but probably affects all TCP communication. The blocks last for up to several minutes, during which there is no obvious server activity (minimum CPU/HDD/Network load), so it looks rather like a timeout. The process eventually resumes (no error message), but the problem repeates soon after (on another blob segment or ddl command). To reproduce the problem, it it sufficient to try to insert a large file (say Firebird installation exe file) into a binary blob field when wire compression is active. In FB 3.0.5 it takes just a second, while in 3.0.6 it would now probably last tens of minutes. Workaround is either to disable the wire compression or switch back to FB 3.0.5. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6050) When FB 3 fbclient.dll connects to a remote FB 2.5 server, it tries to open local (client-side) directories and files
When FB 3 fbclient.dll connects to a remote FB 2.5 server, it tries to open local (client-side) directories and files - Key: CORE-6050 URL: http://tracker.firebirdsql.org/browse/CORE-6050 Project: Firebird Core Issue Type: Bug Components: API / Client Library Affects Versions: 3.0.4 Environment: Windows 10, FB 2.5.8, fbclient.dll 3.0.4 Reporter: michalk1 When FB 3 fbclient.dll connects to a remote FB 2.5 server, it tries to open local (client-side) directories and files. isql -user sysdba -password masterkey remotehost/3050:D:\Test.FDB ProcessMonitor run on the client side reveals that isql attempts to read local (client-side) files and directories. The remote connection is then successfully established, but if the client-side drive is a specific type (internal card reader etc.), the affected application may fail with an error message "There Is No Disk in the Drive. Please Insert a Disk into Drive \Device\harddisk1\Dr1". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6023) FB4 unable to overwrite older ods database
FB4 unable to overwrite older ods database -- Key: CORE-6023 URL: http://tracker.firebirdsql.org/browse/CORE-6023 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 4.0 Beta 1 Environment: Windows 10, FB 4.0 Beta 1 Reporter: michalk1 Priority: Minor FB4 is unable to overwrite database files created by older firebird versions. It concerns gbak restore (with -rep switch) and database creation functions, even when run under sysdba account. This is probably not an error per se, but it differs from FB3 and can complicate automated database migration process. gbak -rep -v -user sydba -password masterkey C:\TEST\TEST.GBK localhost:C:\TEST\TEST.FDB ... gbak: ERROR:unsupported on-disk structure for file C:\TEST\TEST.FDB; found 11.2, support 13.0 gbak: ERROR:IProvider::attachDatabase failed when loading mapping cache gbak: ERROR:failed to create database localhost:c:\TEST\TEST.FDB Local (embedded) connections are not affected, only TCP ones. Strangely, when embedded overwriting is tested first, the server seems to remember that it has successfully accessed this database file, so that subsequent TCP rewrites of the same file (that I each time replace by the original old database) now succeed as well. This lasts until server is restarted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-6019) Wire compression not working without MSVC 2010 runtime installation (FB4 Beta1)
Wire compression not working without MSVC 2010 runtime installation (FB4 Beta1) --- Key: CORE-6019 URL: http://tracker.firebirdsql.org/browse/CORE-6019 Project: Firebird Core Issue Type: Bug Affects Versions: 4.0 Beta 1 Environment: Clean, older Windows 7 and 10 versions, without updates Reporter: michalk1 Priority: Minor Wire compression (WireCompression = true in firebird.conf at client side ) is not working on some older Windows hosts (Win10 1803, Win7). A workaround is to download and install MSVC++ 2010 redistributable package. FB 4 installer contains VC2017 runtime, but wire compression (zlib1.dll ?) is probably still tied to the older version. Remote TCP connections fail instantly: isql -user sysdba -password masterkey testhost:employee Statement failed, SQLSTATE = 08006 Error reading data from the connection. Local TCP connect succeeds, but it's wire compression is not active, probably because compression fails sooner, already at the client side. Btw., I'm not sure whether Win XP are still supported, but my attempts to test FB4 Beta1 on them failed. First problem was in installation, which in it's final part displayed several error messages "This application has failed to start because api-ms-win-crt-runtime-l1-1-0.dll was not found.". But even when I fixed it by installation of another MSVC runtime (2015) and the installation completed, I was unable to connect from isql to employee database, FB log file says "Could not find acceptable ICU library". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5892) SQL SECURITY DEFINER context is not properly evaluated for monitoring tables
SQL SECURITY DEFINER context is not properly evaluated for monitoring tables - Key: CORE-5892 URL: http://tracker.firebirdsql.org/browse/CORE-5892 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 4.0 Alpha 1 Environment: FB 4.0.0.1163 Win32 snapshot build, Windows 10 Reporter: michalk1 The new FB4 SQL SECURITY feature doesn't seem to work properly when used together with monitoring tables (copied from CORE-2557 comments): The following procedure created by SYSDBA returns all connections when run by SYSDBA. But when run by an ordinary user, it sees only that user's connections. CREATE PROCEDURE TEST RETURNS (CONCNT INTEGER) SQL SECURITY DEFINER AS BEGIN select count (*) from mon$attachments into :CONCNT; suspend; END^ GRANT EXECUTE ON PROCEDURE TEST TO PUBLIC^ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5515) When 32bit and 64bit FB 3 servers run on one Windows machine concurrently, Firebird services freeze several minutes after first disconnect.
When 32bit and 64bit FB 3 servers run on one Windows machine concurrently, Firebird services freeze several minutes after first disconnect. --- Key: CORE-5515 URL: http://tracker.firebirdsql.org/browse/CORE-5515 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0.2 Environment: FB 3.0.2.32703, tested at two independent machines with Windows 10 and Windows 2016 server. Reporter: michalk1 Steps to reproduce: 1) Install FB3.0.2 64bit with default settings (port 3050, service name DefaultInstance) 2) Use FB3.0.2 32bit zip package to install another FB instance at the same machine, change its RemoteServicePort in firebird.conf (e.g. to 3051), setup its security database and use svcmgr to configure and start the service (named say FB30) instsvc i -n FB30 instsvc start -n FB30 3) Run isql from DefaultInstance server and make TCP connect to its employee database isql -user sysdba -password masterkey localhost/3050:employee 4) Run isql from FB30 server instance and connect to its employee database as well isql -user sysdba -password masterkey localhost/3051:employee 5) Close both connections and isql consoles (ctrl+z) 6) Wait at least two minutes 7) Now, when trying to connect again to any database, isql console freezes. Both FB services are stuck as well and must be killed from task manager. Clues: The problem is not isql or database specific, you can use i.e. FlameRobin, and connect to any database to demonstrate the problem. What is weird is the time limit required in step 6, because when the new connection is established fast enough (in less than about those two minutes), everything continues to work. Two FB 3 64bit or two 32bit servers work together ok, it is only combination of 32bit and 64bit servers that cause hangs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5104) External data source selects became slow
External data source selects became slow Key: CORE-5104 URL: http://tracker.firebirdsql.org/browse/CORE-5104 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0 RC1 Environment: Windows 32bit, Firebird superserver with default configuration Reporter: michalk1 Since original FB3.0 RC1 release the execution of external selects became very slow. It seems that the connection is now not reused anymore and a new one is opened with every select. Ie., the following simple statement, which in FB 3.0.0.32136 was able to run 500 times per second, in the current snapshot build 3.0.0.32323 went down to 6/s. EXECUTE BLOCK RETURNS (Cnt INTEGER) AS begin EXECUTE STATEMENT 'SELECT COUNT (*) FROM RDB$DATABASE' ON EXTERNAL DATA SOURCE 'C:\TestDb.Fdb' WITH COMMON TRANSACTION AS USER 'sysdba' PASSWORD 'masterkey' INTO :Cnt; suspend; end Btw., the database connect itself is now slower than is used to be in FB 2.5. Where FB2.5 made 15 connections/second (connect and disconnect repeatedly), FB3.0 now does just 5 per second. But for common attachments this is probably not as important (can be workaround with connection pool if needed). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5102) FB3.0 RC1 Fbclient.dll function calls modify FPU control word
FB3.0 RC1 Fbclient.dll function calls modify FPU control word - Key: CORE-5102 URL: http://tracker.firebirdsql.org/browse/CORE-5102 Project: Firebird Core Issue Type: Bug Components: API / Client Library Affects Versions: 3.0 RC1 Environment: Windows Reporter: michalk1 Priority: Minor This is almost similar to CORE-4043, which was fixed in 2.5.3. In FB3 RC1, FPU returns with all flags masked, ie: before call 1 00 11 00 110010 (0x1332) after call 1 00 11 01 11 (0x137F) All remote functions seem to be affected (isc_attach_database, isc_dsql_execute2, isc_dsql_fetch, isc_dsql_free_statement, isc_commit_transaction, isc_service_start etc.) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-5003) Implement pre-ODS 12 provider
Implement pre-ODS 12 provider - Key: CORE-5003 URL: http://tracker.firebirdsql.org/browse/CORE-5003 Project: Firebird Core Issue Type: Improvement Components: Engine Affects Versions: 3.0 RC 1 Reporter: michalk1 As I read in Firebird 3.0 RC1 Release Notes, FB 3.0 doesn't include pre-ODS 12 provider, and it may only be implemented in future. Please reconsider this, I think that it's quite important to have providers for one or two previous FB versions, especially to simplify the upgrade process. Without them, unlike previous major upgrades, upgrade to FB 3 would require to go the classical hard way - backup all databases first under previous FB version, uninstall old Firebird, install Firebird 3, and restore the backups. While this is trivial task for an in-house database administrator, it's quite difficult to achieve automatically by installation process at customers' sites, without user's intervention. I think that FB should allow easier upgrade path and be able to read older versions databases. Full feature work with older ODS may not be necessary, but new Firebird version should at least be able to make backup of the older ODS databases on its own, just as previous FB versions did . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4585) Can't create column check constraint when the column is domain based
Can't create column check constraint when the column is domain based Key: CORE-4585 URL: http://tracker.firebirdsql.org/browse/CORE-4585 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 3.0 Beta 1 Environment: WI-T3.0.0.31384 Firebird 3.0 Beta 1, Windows XP (32-bit) Reporter: michalk1 The following table creation statement throws an error in FB 3.0.0.31384. It works correctly in FB 2.5. CREATE DOMAIN dMYINT AS INTEGER; CREATE TABLE TEST ( TESTFLD dMYINT CHECK (TESTFLD 0) ); unsuccessful metadata update CREATE TABLE TEST failed Dynamic SQL Error SQL error code = -203 Inappropriate self-reference of column -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4224) Database replace through services API fails
Database replace through services API fails --- Key: CORE-4224 URL: http://tracker.firebirdsql.org/browse/CORE-4224 Project: Firebird Core Issue Type: Bug Components: Engine Affects Versions: 2.5.3 Environment: Windows XP Reporter: michalk1 Gbak in service mode now fails to overwrite a database. The problem is specific to current FB2.5.3 snapshot builds, previous release version (2.5.2) is ok: gbak -REP -USER sysdba -PASSWORD masterkey -SERVICE localhost:service_mgr C:\test.gbk C:\test.fdb gbak: ERROR:could not drop database C:\test.fdb (database might be in use) gbak: ERROR:Exiting before completion due to errors Nevertheless, the replaced database file is removed by previous gbak call, so the next call of the same gbak command is successfull (since the file to overwrite is now missing). Once the database file exists, however, gbak fails again. To be sure that the file is really not in use, I even tried to stop the server before the gbak call, but it didn't help. The same problem can be demonstrated by fbsvcmgr: fbsvcmgr localhost:service_mgr -user sysdba -password masterkey action_restore verbose res_replace -dbname C:\test.fdb -bkp_file C:\test.gbk gbak:opened file C:\test.gbk could not drop database C:\test.fdb (database might be in use) -Exiting before completion due to errors -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4110) FB 2.5 Windows installer doesn't detect existing FB 2.1 install
FB 2.5 Windows installer doesn't detect existing FB 2.1 install --- Key: CORE-4110 URL: http://tracker.firebirdsql.org/browse/CORE-4110 Project: Firebird Core Issue Type: Bug Components: Installation Affects Versions: 2.5.2 Update 1 Environment: Windows 7, Windows XP Reporter: michalk1 Priority: Minor The FB 2.5 Windows installer doesn't detect existing FB 2.1 install and as a result, overwrites it's service settings. Steps to reproduce: - Install Firebird 2.1.5, default settings - Stop the Firebird service - Install Firebird 2.5.2, default settings Now, the only installed service is the FB 2.5 one. The correct behaviour should be to show a warning message: If you continue with this installation Firebird will be installed but not configured. The bug is probably in the following fragment of AnalysisAssessment function in file FirebirdInstall_20.iss, which was left unmodified since FB 2.1 (another resembling suspicious code is in SummarizeInstalledProducts function): function AnalysisAssessment: boolean; ... //If existing install of the same majorver.minorver is //found then we can upgrade it. if ( (ProductsInstalledCount = 1) AND #if PlatformTarget == x64 ((ProductsInstalled AND FB21_x64 ) = FB21_x64 ) ) then begin #else ((ProductsInstalled AND FB21 ) = FB21 ) ) then begin #endif result := true; exit; end ; ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-4053) Provide a way to rename or copy database file
Provide a way to rename or copy database file - Key: CORE-4053 URL: http://tracker.firebirdsql.org/browse/CORE-4053 Project: Firebird Core Issue Type: New Feature Components: Engine Reporter: michalk1 The recommended way to restore a database file is to restore it under temporary filename, and only when it's succesfully created, replace the original database file. However, the engine currently doesn't offer any support for this action (file rename or copy operation), that could be controlled from an application running at a remote client station. Such a feature would simplify database restoration process and other database actions, that must be executed on a database copy. Studying archives, I found several workarounds, none of them being perfect: - Write a udf library with that functionality - requires every developer to maintain and install several versions of such a library (Win/Linux, 32bit/64bit, ...). Customers can't run Firebird out of the box. Such a udfs may be also prone to errors, because developers may not be aware of FB file locking etc. - Server-side backup and restore (through services API) of the database to rename it - works, but is slow and requires fallback plan (in case of a power failure during restore process etc.). - Server-side backup and restore by the new nbackup services API in FB2.5. Much faster than gbak, but still not as fast as a simple file rename or copy. Furthermore, nbackup doesn't allow to overwrite the intermediary nbk file. Every run must be executed with a different temporary filename, which causes the nbk files to pile up, and there is no way to delete them from the client station. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tracker.firebirdsql.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
