Tips:How to Identify if your run 64 bits of Firebird engine

Question: I have a requirement to Identify whether a Firebird system is 64 bit or not,in order to know whether to deploy a 64 bit UDF or a 32 bit UDF. Is there any thing to give the correct information?
The best Answer: Identify this information this way:
fbsvcmgr service_mgr -user sysdba -password masterke -info_server_version -info_implementation

see the manual for more  : http://firebirdsql.org/rlsnotesh/rlsnotes210.html#rnfb210-util-svcs

On ubuntu/debian 64 will give :
fbsvcmgr service_mgr -user sysdba -password masterke -info_implementation | grep 64
Server implementation: Firebird/linux AMD64

or you can count if the 64 string is present with -c in grep (notice that there is no need for username and password)

fbsvcmgr service_mgr -info_implementation | grep -c 64

1



 

Jiří Činčura Blogged: Tokenize string in SQL (Firebird syntax)

Few days ago I wrote “Some thoughts on denormalization” post. Though concatenating data to one string is easy with there introduced function, splitting it back could be harder. I left it as exercise, but I feel, to make it complete, it’s good to show one possible implementation.

Here’s one I came with today (using Firebird syntax, however it’s almost pure SQL), quickly. It’s something I created from start to finish in one row and sure for some cases it could be optimized.

 

Using Firebird inside Azure (without VM role)

Here are the notes on using Firebird Embedded in Azure

Recently I was playing with Amazon EC2 trying what I could use it for. I was playing with Firebird there as well. But in fact you have virtual machine you can use. So using Firebird there wasn’t that hard. But I got and idea about Azure, because it’s more platform for applications than computers.

Then the VM role was introduced and the challenge was somehow not so challenging.

Change made to make Faster restores with gbak

There is a simple change which makes restores much faster, tested with Linux 2.5 embedded restore
Two databases, with two different tables filled with 2,000,000 records:
create table t1 (n1 integer);
create table t10 (n1 integer, n2 integer, n3 integer, …, n10 integer);

----------------------
Restore timings:
T1: 14.5s
T10: 20.5s

Improved gbak timings:
T1: 9.7s
T10: 14.7s
----------------------

The good news is there is still room to improve the restore speeds , here is Adriano’s tweet:

I do have a slight different method, to insert 100K records in less than 1s over the same localhost method.

Also confirmed by the ending of the article:

PS: There is other restore improvement capable of take down time from
around 8.5s to 0.5s over TCP, but it still requires some analisys.

1 20 21 22 23 24 78