[Firebird-devel] FW: Delphi application and Firebird 2.5 client
Hi all, I have posted this to firebird-support and there was no reply ... so I repost it here. The problem is that in Delphi some runtime exceptions are not catched with 2.5 client ... with every other older FB client everything is OK. More in original post Thank you for help. Best regards, Simon I have a Delphi database application that is currently running on FB 2.5 server. Application was working OK for several years on previous FB versions. I switched to FB 2.5 early when it was released. This year I noticed a couple of cases when there was INF value written in double precision field in database. I also noticed, that Delphi Try / Except / End block was not catching EZeroDivide etc. exceptions ... this is big problem. Imagine case like this: var A,B,C: Real; try C := A / B; // B is zero here except C := 0; end Exception is not raised on C calculation and C is calculated as INF. Well I can change that and check if B is zero and do workaround, but there is Delphi VCL that depends on exception being raised! That is why Delphi sets FPU Control Word to $1332 to raise exceptions. You can read more about that here: http://qc.embarcadero.com/wc/qcmain.aspx?d=5928 So, when I was looking for DLL that my application loads that disables FPU exceptions I realised that it is Firebird Client library or its MSVC RTL. What I found out is that my delphi application is catching exceptions if I use FB client from version 1.5 up to version 2.1.4, but not with FB 2.5 client. Now I wonder if it is FB Client that is builded with disabled FPU exceptions catching or is it MSVC RTL. I dont know if MSVC RTL changed from FB 2.1.4 to FB 2.5 or it is the same. If I set FPU CW to $1332 manualy in my application it works only for a couple of lines of code than it is back disabled again, so this is not a solution. Currently I am using 2.1.4 client to be on the safe side. Does anybody knows what changed in FB 2.5 and what can be done about it? Thank you and best regards, Simon -- View this message in context: http://firebird.1100200.n4.nabble.com/FW-Delphi-application-and-Firebird-2-5-client-tp3887344p3887344.html Sent from the firebird-devel mailing list archive at Nabble.com. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
[Firebird-devel] [FB-Tracker] Created: (CORE-3642) In-memory database - opening read-only database from memory rather than from file in FB Embedded
In-memory database - opening read-only database from memory rather than from file in FB Embedded Key: CORE-3642 URL: http://tracker.firebirdsql.org/browse/CORE-3642 Project: Firebird Core Issue Type: Improvement Components: API / Client Library Affects Versions: 2.5.1 Reporter: Dmitry Replacing application-internal data stractures with some data warehouses has a long history. Once it was in-memory ISAM tables with manual sorting/indexing As CPU/memory increased, solutions like generic SQLite(having 'in-memory' mode) or language-specific NexusDB/sqlMemTable appeared. Latter has drawback that when new Language version is rolled out they usually lag behind for quite a while. SQLite is popular, but not as feature-rich as FB and language-specific access components might be worse for some languages (especially Delphi lineup) than for FB. However generally converting file-based database into memory-based would be to complex goal to worth doing/asking for. But not now, i feel. General Temporary Tables were introduced into FB quite ago. And with 2.5.1 release GTTs can be used fully even in generally read-only database. So all the code for in-memory tables, indexes, views etc is in place. Metadata can't be changed but it arguably may apeear 'right thing' for the in-memory database: not using 'db genearator script' but using readymade database file with ready-made data access components bindings. Also this aligns well with Windows restriction that in-memory file should have pre-defined length and never grow (if implementation would use file handles API for bootstrapping, this easy way is okay probably, since 'tis only needed to read headers once on r/o database). What i feel is left to be implemented: 1) database file opening from memory in FB Emb 1.1) either only-r/o databases 1.2) or every database, if pened 'in-memory' should be treated effectively r/o All the actual work is to be shared between persistent VIEWS/TRIGGERS/PROCEDURES 2) bonus: UDF support in-memory. Not via extra files but again via function pointers Nice thing, though not necessary, and can be done anytime later. 3) bonus: EVENTs posting via common connection stream (X-NETc in-memory stream for FB-Emb), rather than separate TCP connection. This can start as FB Emb optimization (TCP requirement for an application to talk to itself is curious artefact) and later generalized into FB-generic enhancement (as done in IB7.1sp1). While this may made diagnostic sometimes more complex, it would made system configuration a bit easier This change can be done anytime later as well. -- 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 -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] 68K port
-=| Alex Peshkoff, 20.10.2011 16:40:04 +0400 |=- Hi, Dam! Can you comment something about this issue: http://tracker.firebirdsql.org/browse/CORE-3637 Telling true I'm surprised. Why is that port needed at all? No idea. People need different things :) May be there is a real park of old 68k machines? Wikipedia mentions that 68k-based architecture based CPUs are used in embedded systems, but apache+php+firebird - is not it too much for embedded device? The server probably is too much, although you never know what people would want to do. Having the client seems like a plausible goal, though. We had that port in FB1, but later cleaned it up. And I see no reasons to return to it. I'd suggest to not put too much effort into that or any other port. Let people interested in the port submit patches. I hope at least there is an implementation ID that is available for use? Did not drop as Won't fix only because it came from Debian :) Very generous from you. Thanks! As I understand it, the request is from a Debian/m68k porter, who aims at reaching high availability ratio for the port in order to make it active again (m68k was officially deprecate when the security support for Debian 3.1 (the last release with m68k) was stopped in March 2008). Since so many core packages need Firebird to build (php5, qt, mono), they are trying to make Firebird available in order to not stop port progress to greater archive coverage. The other possible approach is to stop the depending core packages build their Firebird functionality and move on, but this is somewhat last resort. I hope this brings some background and makes intentions clearer. -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
