[firebird-support] HP 200LX .gdb files?
Hi Folks, I am searching for a Macintosh OS X solution which supports .gdb database files from the Hewlett Packard HP 200LX Palmtop. I understand that Firebird can be installed on OS X, but need to know if there might still be support for the .gdb files produced by the 200LX. (I belong to an HPLX Support Group which has a couple of hundred members who are still using their HPLX devices on a regular basis.) I would appreciate any pointers to where I might find the relevant information. Thanks very much in advance! Larry
Re: [firebird-support] HP 200LX .gdb files?
Larry, I am searching for a Macintosh OS X solution which supports .gdb database files from the Hewlett Packard HP 200LX Palmtop. I understand that Firebird can be installed on OS X, but need to know if there might still be support for the .gdb files produced by the 200LX. (I belong to an HPLX Support Group which has a couple of hundred members who are still using their HPLX devices on a regular basis.) I would appreciate any pointers to where I might find the relevant information. Thanks very much in advance! I doubt this is a InterBase/Firebird database. I guess you are more seeking for: http://www.usinglinux.org/databases/p5-hp200lx-db.html -- With regards, Thomas Steinmaurer http://www.upscene.com/ Professional Tools and Services for Firebird FB TraceManager, IB LogManager, Database Health Check, Tuning etc.
Re: [firebird-support] Database Size Is Not Reducing
On 07.04.2015 08:16, Vishal Tiwari vishuals...@yahoo.co.in [firebird-support] wrote: Then what could be the best way to reduce the database size? All suggestions are appreciated. Hej Vishal played around a little bit, unable to reproduce your problem. Even after setting some blobfields to NULL, leaving isql or flamerobin open and the update statement uncommitted, gbak -b with -l or -g or -l and -g : the backup files are all distinctly smaller than the backup with all blob content. Same for all the restored databases. What i've done: - System Win7 64, FB 2.5.2 - created a new database, new table t1 (id integer, blobfield blob subtype 0), all operations in the same directory - create first backup for empty db - insert 10 ids and random blob data - create second backup - update t1 set blob=null where id 2 - leave either flamerobin or isql statement uncommited - backup db to different names: both smaller than second backup - playing with backup options, backup to different names: still smaller than than the second backup - commit statement - backup db to different names: both smaller than second backup - playing with backup options, backup to different names: still smaller than than the second backup - restore all the backups to according names: size equals between all backups where i've done the update...set...null, all smaller than the original database with all 10 blobs. - opened all databases: blobs 3..10 are NULL So, question is: how do you do your backup/restore? cmd, service api, some 3rd Party components? Doublechecked file locations? Stumpled upon that to often for myself. hth, Marcus With Best Regards. Vishal [Non-text portions of this message have been removed]
[firebird-support] Re: How do I uninstall Firebird on Mac Yosemite?
How do I know which directory the remove.sh file is in? Can I find it from within the Finder? How do I find it using Terminal? How do I change directories to get into the directory that the file is in?
[firebird-support] Re: How do I uninstall Firebird on Mac Yosemite?
I tried it out and it said the following: Ryans-MacBook-Pro:~ ryanashton1$ ./remove.sh Launchctl /Library/LaunchDaemons/org.firebird.gds.plist: Could not find specified service Remove Framework Remove Receipt Remove /tmp/firebird
RE: [firebird-support] Recursive CTE question
Can the question be rephrased as you being interested in which sets are identical, Elias? If I understand things correctly, I would assume double negation to be the simple answer you're looking for: with tmp(id) as (select distinct id from CRITICALPARAMVALS) select t.id, t2.id from tmp t join tmp t2 on t.id t2.id where not exists(select * from CRITICALPARAMVALS a where t.id = a.id and not exists(select * from CRITICALPARAMVALS b where t2.id = b.id and a.PARAM=b.param and (exists (select isequal from TEST_FLOAT_EQ(a.val, b.val, 1e-5) where ISEQUAL=1 Sorry, the above select returns equal sets, but also sets where B is a superset of A. You need to add and not exists(select * from CRITICALPARAMVALS a where t2.id = a.id and not exists(select * from CRITICALPARAMVALS b where t.id = b.id and a.PARAM=b.param and (exists (select * from TEST_FLOAT_EQ(a.val, b.val, 1e-5) where ISEQUAL=1 for it to only find identical sets. Needless to say, such a query can be a bit slow with huge tables. Moreover, I don't know how TEST_FLOAT_EQ is implemented or why you use this rather than a.val BETWEEN b.val - 0.1 and b.val + 0.1 HTH, Set
RE: [firebird-support] V1.56 query killing my V2.54 app
Ok, used the +0 and worked. On v1.56 I was used with setting up a high granularity data column (col04Int - part of the primary key) with a True/false (0/1) type of column (ColDetSmIntFlag) to boost the selectivity of the index IXColDetSmIntFlag. I kept the index with that configuration for a just in case. (The stat of the index is 0,01407...) Set, don't get me wrong, I am very gratefull for your help and for Firebird, but saying that a Natural on a big table seems better than an index doesn't compute for me, and I've been using Firebird since Interbase and Oracle since v6 (as DBA BTW). At a least case scenario it should use the PK when there is a declared join using the PK. For me, the new optimizer is wierd and highly illogical. Glad to hear that +0 worked. We used Fb 1.5 for a long time (switched from 1.5 to 2.5 a year or two ago) and I’m happy to say that my impression generally is that the optimizer in 2.5 is better than it was in 1.5 and that the need for tricks like +0 is less than it used to be. Though there will of course be differences, and it is not a surprise that you notice some drawbacks rather than benefits when upgrading a particular database (I assume you have optimized poorly performing queries with Fb 1.5 long ago, rather than been waiting for the upgrade). If you compare new, unoptimized queries between 1.5 and 2.5, odds are that you would conclude that 2.5 are better. I guess the reason for the optimizer preferring the NATURAL plan is a combination of msttbl having about half the number of records of dettbl and the index on ColDetSmIntFlag having lousy selectivity (the optimizer doesn’t have histograms yet (I am uncertain whether histograms are part of Firebird 3 or if it will be a later release), and doesn’t know that 1 is a less frequent value than 0). Set
Re: [firebird-support] V1.56 query killing my V2.54 app
On 07 Apr 2015 08:51:22 -0700, andrew_s_...@yahoo.com [firebird-support] firebird-support@yahoogroups.com wrote: Hi all, I'm trying to upgrade an app to v2.54 from v1.56 but there are some queries that aren't planning the way they should. I've been changing the query and trying to change indexes to no success. Is there a way to force FB 2.54 to chose the right indexes? Did you update the index statistics? Maybe your statistics are out of date. Mark
Re: [firebird-support] Re: V1.56 query killing my V2.54 app
On Apr 8, 2015, at 10:05 AM, andrew_s_...@yahoo.com [firebird-support] firebird-support@yahoogroups.com wrote: Let's see when histograms come to the party, it'll make things more interesting for sure. G Histograms may be less useful in Firebird than you might think, unless there's a lot of work done in query preparation. In order to use the fact that there are lots more 0's than 1's in a two valued index effectively, Firebird has to know whether you're looking for a 1 (good) or as 0 (forget the index). Firebird queries are optimized when they are prepared, so without major changes, the histogram is useful only for literal values - not parameters. Probably a query could be partially optimized at prepare time and have a final optimization when the query is executed and all paramters are known. However, there's also the case where values become known ony during the execution of a join. Should Firebird do a row-by-row optimization of a nested loop join? I wonder if you tripped over an improvement in Firebird. In 1.5, Firebird kept only the total selectivity for compound indexes. More recent versions keep the selectivity at each column - e.g. if you have a two valued column as the first part of an index and a very selective colum next, Firebird 1.5 considered the index a good candidate, even if you only matched the first part. In later, smarter versions, it recognizes that the first part alone is not very good. Good luck, Ann
[firebird-support] Re: V1.56 query killing my V2.54 app
Hi Mark, Yes, I did a Backup/Restore and updated all the index statistics to give the engine the best chances possible for the select... Thanks. Andrew
[firebird-support] Re: How do I uninstall Firebird on Mac Yosemite?
I tried it out and it said the following: Ryans-MacBook-Pro:~ ryanashton1$ ./remove.sh Launchctl /Library/LaunchDaemons/org.firebird.gds.plist: Could not find specified service Remove Framework Remove Receipt Remove /tmp/firebird Then the sh file has done nearly all its job... the comments you see above refer to the echo commands in the shell script But I have just seen a small problem with why you still have a firebird user... The original had the remove user/group commands commented out. Apologies. just type the following into the terminal and hit return sudo dscl localhost -delete /Local/Default/Users/firebird sudo dscl localhost -delete /Local/Default/Groups/firebird The following script is now complete. #!/bin/sh echo Launchctl launchctl unload /Library/LaunchDaemons/org.firebird.gds.plist echo Clean User dscl localhost -delete /Local/Default/Users/firebird echo Clean Group dscl localhost -delete /Local/Default/Groups/firebird if [ -f /Library/StartupItems/Firebird ]; then echo Remove Superserver StartupItem rm -fr /Library/StartupItems/Firebird fi if [ -f /Library/LaunchDemons/org.firebird.gds.plist ]; then echo Remove Launchd launchctl unload /Library/LaunchDemons/org.firebird.gds.plist rm /Library/LaunchDemons/org.firebird.gds.plist fi echo Remove Framework rm -fr /Library/Frameworks/Firebird.framework echo Remove Receipt rm -fr /Library/Receipts/Firebird*.pkg echo Remove /tmp/firebird rm -fr /tmp/firebird Paul
[firebird-support] Re: V1.56 query killing my V2.54 app
Hi Set, (I assume you have optimized poorly performing queries with Fb 1.5 long ago, rather than been waiting for the upgrade). Yes. If you compare new, unoptimized queries between 1.5 and 2.5, odds are that you would conclude that 2.5 are better. I have very high expectations for that. On my initial tests everything seems faster. But I'm still testing everything. My app is rather busy and considering that this query in question should be performed in 6 seconds and went to 2 minutes... but now it's back to it's 6 seconds, thanks to you. Let's see when histograms come to the party, it'll make things more interesting for sure. G Thanks again Andrew
[firebird-support] SQL puzzle: Order based on Prerequisite
In a table called Steps, I have the following fields: ID, B4Me, Dsc, -ID field contains a unique ID for each record -B4Me contains the ID of some other record in the table that MUST appear in a result set, BEFORE this record. B4Me may be null. This is called the B4Me order. -Records will be entered in random order, so Natural order cannot be relied upon as a substitute for B4Me I need an SQL statement that will return all records with a user supplied search word (such as oil, or glycol or micron) in the Dsc field, which could return a variable number of records, but what ever the number of records returned, the *order* must be such that each record is preceded by the record who's ID matches the B4Me value of a given record. Important Notes: - The SQL may return one or more records with a blank B4Me. In which case, Natural order can be used for those records, and they are all considered First or rather, Before everything else. Once all the records with a blank B4Me are listed, the remaining must be in the B4Me order. - It is possible, though unlikely, that following the B4Me order will result in a circular reference. (Two or more records that reference each other, or the last record in a large result set, references the first (or any other in the result set) record in the B4Me field). In these cases, the SQL must either list all records until a circular reference is detected, then don't list the offending record, or display an error message, but it must not hang FB and get an out of memory error. Thanks in advance for any help you can provide.
[firebird-support] Re: V1.56 query killing my V2.54 app
Hello Ann, Firebird 1.5 considered the index a good candidate, even if you only matched the first part. In later, smarter versions, it recognizes that the first part alone is not very good. I did change the index to only the boolean 1/0 field... then I changed back adding a part of the primary key to boost a high graularity on the index trying to make things work as I needed. After removing the compuond part and running some tests with and without the +0 on the query I got: With the +0 PLAN SORT (SORT (JOIN (B INDEX (IXColDetSmIntFlag),A INDEX (PK_msttbl Prepare time = 47ms Execute time = 2s 968ms Avg fetch time = 102,34 ms Current memory = 2.129.816 Max memory = 2.201.604 Memory buffers = 75 Reads from disk to cache = 302 Writes from cache to disk = 0 Fetches from cache = 1.555 without the +0 PLAN SORT (SORT (JOIN (A NATURAL, B INDEX (FK_dettbl Prepare time = 16ms Execute time = 1m 20s 562ms Avg fetch time = 2.778,00 ms Current memory = 2.124.564 Max memory = 2.201.604 Memory buffers = 75 Reads from disk to cache = 157.563 Writes from cache to disk = 0 Fetches from cache = 2.909.887 Apparently I made it slightly better using some of v2.5x improvements. After more than a decade of Firebird I'm more than used to using the +0 to get the results desired from the engine but still, I find it illogical that scanning a table with NATURAL doesn't have a much higher cost than any other index to the engine. Well... new engine, new lessons. Thanks. Andrew
