Firebird News

Thursday, March 30, 2006

Then they laugh at you

ot only does open source Firebird-Fyracle have a catchy name and almost match Oracle on the 6 well known “gold standard key database evaluation mapping criteria”, but it is “just as idiosyncratic”, AND you can run “Compiere v2.5.3c” ( almost )!

Here is the response from shocked oracle users after they found Firebird/Fyracle (Denial Mode)

Permalink

.:():..:():..:():..:():..:():.

20GB of video data available, with around 100 hours of firebird related presentations from Firebird Conference

Here is the list of available Films

What is IBExpertLive?

HK-Software has implemented a streaming system based on the Firebird database server, which publishes pictures and audio, as needed to view the presentations from the 2004 and 2005 Firebird Conferences. We will also be adding IBExpert tutorial videos enabling you to learn more about working with Firebird and InterBase with IBExpert.

There is currently about 20GB of video data available, with around 100 hours of firebird-related presentations from last two Firebird Conferences and other events.

To use IBExpertLive, you need a firebird connection via Internet using port 13050 to our server on IP 80.237.154.78. If it does not work, please check your firewall settings. For reporting any other questions/problems regarding IBExpertLive, please use the following contact addresses:

IBELive newsgroup: hk-software.ibexpert.live (English, German and Russian language).

E-mail: ibexpertlive at ibexpert.biz.

There might be some videos that are not working yet, even if they are on the list. Please bear with us; we'll have everything up and running as soon as possible.

The download address is: www.ibexpert.com/ibexpertlive/IBExpertLive_setup.exe



.:():..:():..:():.

Wednesday, March 29, 2006

google reader firebird

Here is the list of feeds i have in google reader

http://forums.devshed.com/rss61.xml
http://fhasovic.blogspot.com/atom.xml
http://www.firebirdsql.org/devjournal/rss.php
http://www.firebirdnews.org/?feed=rss2
http://firebirdnews.blogspot.com/atom.xml
http://flamerobin.blogspot.com/atom.xml

I had the firebird-support added but it was too much for
google reader (scrolling between many posts)

.:():..:():..:():.

The Firebird ADO .NET Data Provider 1.7.1 for .NET 1.1 and Mono 1.1 is available for for download.

Download information can be found here ·

· 1.7.1 ( 2006-03-29 ) ·

(Please read the Changelog for details)

Bug Fixes:

- Fixed bug #1417618

- Minor fix on Guid datatype infer.

Changes:

- Changes to try to avoid problems with IPV6.

- Added new synonym for the user identification ( userid ) in
connection strings.

New features:

- Added initial support for EXECUTE PROCEDURE commands in
FbBatchExecution class.


Carlos Guzmán Álvarez
Vigo-Spain

http://carlosga.blogspot.com/



..::::..::..::..::..::..::..

fyracle - oracle replacement blog of the day

I won't be suggesting this as a replacement for my Oracle production databases anytime soon, but it might be worth looking at for some applications.


..::::..::..

Tuesday, March 28, 2006

Google blogsearch drowning in spam

I agree with that
Try to search Firebird on the google search (and sort it by Date)
ps: i tweak-ed the search a little eliminating the auto,body, parts articles
Now even tehnocrati.net is starting to get spammed (Search for firebird+database)
..::::..:():..:():..:():..:():..

Sunday, March 26, 2006

Firebird source code reviews

Claudio Valderrama wrote:

"Recently, Coverity presented their first results in their scanning technology that hunts for defects in source code. One of the addressed projects was Firebird. After Roman Rokytskyy reviewed the results, he concluded the failures are in two areas ..."

..::::..

Friday, March 24, 2006

New acronyms FLAPS , FWAP, FWIP

FLAPS is FLAP with ssl (that is s for)

FWAP is an acronym for the combination Microsoft Windows, Apache, Firebird and one or more of Perl, PHP and Python. It is modelled after the more well-known FLAP, referring to the all-open source/free software approach which uses Linux instead of Windows.
FWIP is the WIMP equivalent (alias) with firebird used instead of mysql
..::::..::::..::::..::::..::::..

FlameRobin whitepaper

it was recently concluded that the original authors have the copyright
on papers that were published at the Firebird Conference, so I decided
to make my paper available to the public.

Some small portion of the text is outdated (based on version 0.4.0),
but you can read about history and basic ideas around the project:

http://www.flamerobin.org/flamerobin_paper.pdf
Thanks,

Milan



..::::..::::..

TurboCASH development implementing Firebird database

From the blog of the day department

This blogger's comment:

I think this is really good news, since the Delphi source code poses a lot of limitations, Delphi being a commercial compiler/IDE. The way I understand it, you basically have to purchase Delphi if you want to customize and recompile the TurboCASH source. The same with BDE-Paradox. I'd really like to see TurboCASH take-off in this direction.

..::::..::::..::::..::::..

Six Reasons Why a Company or Business should consider Blogging

I sent an email to one of my freelance clients regarding the advantages of having a blog site, and I thought it would be nice to share them with you.

..::::..::::..

Let there be Fire - morfik site revamped

Today I was glad to see the new website of Morfik Technology was unveiled. Along with a totally redesigned web site, comes the public release of a test version of the their WebOS AppsBuilder tool. These transformations probably reflect a move by Morfik, to bring the development of the WebOS AppsBuilder into the light, after being kept in the shadows for quite some time.


Ed:if you don't know what is the link between firebird and morfik here is an e-mail interview with the Morfik team



..::::..::::..::::..::::..

MSSql difficult to configure? switch to firebird

However I don't like MSSql server, first of all it is hard to configure, finding solutions to problems is not an easy task, it has lots of dependencies scattered around the hard disk. Hail mysql and firebird.


..::::..::::..::::..

Postgres, SQLite, Firebird are all by boring Americans

It occurs to me that the Unix world is truly international. The new addv-thingy (no title yet, I might reuse SFIC, don't know) is going to be written for Ruby on Rails. The Ruby part is from Japan, and is therefore probably written by catgirls and/or ninjas. Maybe catgirl ninjas. (If such do not exist, they should.) Rails, on the other hand, comes from Denmark and is full of viking goodness. Now if I only could find a database from an as-yet-unrepresented region of the world. MySQL is Swedish, but I think that may be overrepresenting Scandinavia. Postgres, SQLite, Firebird are all by boring Americans, and I ought to be the only boring American on this project. Ah well, geeographic diversity ain't everything.

http://beinsane.livejournal.com/56919.html?view=48727#t48727

..::::..::::..::::..::::..::::..::::..

Thursday, March 23, 2006

New Debian firebird2 packages fix denial of service

Aviram Jenik and Damyan Ivanov discovered a buffer overflow in firebird2, an RDBMS based on InterBase 6.0 code, that allows remote attackers to crash.

The old stable distribution (woody) does not contain firebird2 packages.

For the stable distribution (sarge) this problem has been fixed in version 1.5.1-4sarge1.

For the unstable distribution (sid) this problem has been fixed in version 1.5.3.4870-3

We recommend that you upgrade your firebird2 packages.



..::::..::::..

firebird in shutdown mode

Shutdown mode prevents everyone other than SYSDBA and the owner from
connecting.

This allows you to safely run metadata scripts etc and be sure no-one
else is connected while this happens.

gfix -shut f 300 aliasname

will terminate all connections after 5 minutes.

To allow logins again, you need to use

gfix -online

Here is the rest of the user's blog discovering this firebird "mode"


..::::..

dbdesc 1.4.1 available

The author wrote


"Yesterday I’ve uploaded a small maintenance release of dbdesc.

These are the changes and bug fixes since version 1.4"



..::::..

Why using Firebird? - Blog of the day

This statement is base on my experience, so maybe it's not true for you. Firebird version that I know for the first time is 1.0 version, since then I fall in love with Firebird (FB).

Read more on this blog

..::::..

New Firebird ODBC Driver (V2.0.0129 and V1.3.0093)

Updated snapshots and builds of the Firebird ODBC Driver (V2.0.0129 and V1.3.0093) are available.

..::::..::::..

Sweet-talking Firebird with Delphi

Australian Delphi User Group Symposium - La Trobe University, Melbourne. Helen Borrie will be giving a session on: Sweet-talking Firebird with Delphi
Writing database applications for a Firebird (or InterBase) back-end is all about conversations. Applications request and Firebird responds. The better the request, the more sweetly the database engine will oblige. In this presentation, Helen will address various techniques that Delphi developers use and explain how rewarding a good understanding of Firebird's personality can be. More details at: ADUG Symposium

..::::....::::..

Friday, March 17, 2006

oracle licensing too expensive for oracle community site

from this thread on the orafaq forum:

“There is no way we would be able to raise the money required to buy a commercial Oracle license.”
“I believe the XE edition is a max of 2gig. htmldb would be free for that, but by the time you add htmldb overhead and users, I gotta think this site has way way more data than what is left out of the starting 2gig. … Standard Edition One would be the next option, at 5 grand per proc.”

maybe oracle will toss a free license their way, but this is a great case study on how useless oracle’s free offerings really are. (to contrast, of course, mysql’s free offering is fully-featured, with no artificial limitations. same with other truly free databases like firebird or the open-source versions of postgresql.)


..::::..::::..::::..::::..

Monday, March 06, 2006

Vulcan threading - needs to be fixed


INTRODUCTION

The point of this email is to call attention to what I think is the most critical outstanding element of the Vulcan project - the reliability of the threading and sharing model. This email is, I'm sure, going to devolve in unexpected ways; I'd ask that you read it carefully and think before replying, but please do reply... I believe the "Vulcan" part of the Firebird community very much needs the input of the rest of you all.

Vulcan currently has two conditionally defined threading models. More accurately, two models describing very different levels of sharing of data structures. They have very different qualities, and I believe neither one (in it's current form, at least) is what we ultimately must have.



SHARED_CACHE

If the symbol SHARED_CACHE is defined (the default currently) then Jim's original Vulcan model of fine-grained threading and data sharing is built. This model works generally on the assumption that most things should be shared if possible, and relatively light-weight locking mechanisms are employed to provide serialization/exclusivity when it is recognized that there is a shared data structure that must be made thread-safe.

Key benefits of this model include a more efficient memory footprint since there are very few redundant copies of data structures in memory. This is at the cost of increased synchronization primitive use; a read that does not actually have any conflicts with another thread must act as if a conflict is possible or imminent, and so there is a performance cost to most data access paths to protect the code from potential collision from other threads.



(NO) SHARED_CACHE

If the SHARED_CACHE symbol is not defined, then a much coarser level of sharing is implemented, more akin to the Classic model - each thread has it's own page cache, and so data structures resolved from the page cache are usually thread-private. When cache coherency between copies of the cache must be resolved, the same locking mechanisms are used as in SHARED_CACHE to support code to invalidate pages and force reloads.

Key benefits include a much faster read performance rate since far less data is shared. The cost of this is that write rates have a disproportionately negative impact on performance since updated pages must be invalidated in every connection's copy of the page cache. Worse, the memory foot print increases linearly with the number of connections and the per-connection page cache must therefore be kept relatively small, reducing the effectiveness of the cache.


THE BIG PROBLEM

The point of all this is that the biggest problem with the SHARED_CACHE model is that it does not work reliably under load. We can argue the merits of the test cases for a while, but putting Vulcan under significant load on a real multiprocessor system causes it to fail, and fail relatively quickly. Sometimes the failure is caused by undiscovered critical sections that need additional locking, but sometimes the failure is a deadlock because the relationship of critical sections wasn't completely predicted when the locks were added.

Based on my experience with the embedded usage scenario for Vulcan, I do not believe that SHARED_CACHE works reliably enough to actually use in its current form. Period.



BREAKING IT DOWN

There are quite a few issues that come from this. Here are many of my thoughts, in no specific order. When I say "we" in the following paragraphs, I mean the entire community of Firebird and Vulcan developers, not just my particular company.


1. The (NO)SHARED_CACHE model is not the long-term future, and only works in server environments where very large amounts of memory can be dedicated to the server and/or connection throttling and pooling mechanisms attempt to mitigate the scalability problem. It is a stop-gap that we introduced because we needed Vulcan to work in a timeframe that matches some of our product delivery dates.

2. The SHARED_CACHE model does not work, and is very very hard to debug. Clearly debugging by careful inspection can go a long way, but presumes that the inspector(s) know what they are looking for and/or understand the intended sharing model clearly. It also requires a lot of time and effort. SAS has thus far been unable to make this work ourselves, in part because the underlying lock manager appears to deadlock for reasons we have not been able to solve.

3. Testing multi-threaded code is difficult, and nearly impossible to do without the right hardware. I'll be the first to acknowledge that this is a significant problem in an open source community where many of the participants are either self-funded or trying to balance business objectives against community involvement and may not have the luxury of dedicating significant hardware to this. We need to find a practical way to resolve the test environment issues so that the core development team (at least) can regularly validate changes.

4. We need an agreed-upon test suite to validate the threading and sharing model. SAS uses a set of tests ("threadtest") that can be variably configured to control the number of simultaneous client connections and the work load. I think we've shared this already, but if not we'll be glad to make it available as a candidate test tool. More importantly, the community needs to agree on a test scenario that is considered a minimum requirement for this scenario that must pass before Vulcan can be considered ready for real users.

5. We cannot accept a system that works "for a while" or "for a few users" and then dies in a horrible way, hard to reproduce and putting data at risk. Its fine for a server to have limits, but those limits should be something that can be determined in advance or predicted at runtime so a thoughtful and reasonable response can be given to clients and tools. Declaring a test scenario unreasonable because it is hard to debug is not acceptable. Declaring a test case unreasonable and yet still guaranteeing that the server has a reasonable response is great.

6. There are volumes written about the difficulty of retro-fitting threading on code never written to support it. This is a very hard thing to do at all, and very very very hard to do well. My point is not to be a naysayer about Vulcan, but to make clear that we must understand that threading the Firebird code base is not simple to implement, test, or debug.

7. This is important because planning for the Vulcan/FB integration needs to take into account a realistic view of the state of Vulcan. If we think that Vulcan is nearly done as a 1.0 release (the timeline published during the conference called for a public release around now, if I recall) then a merger really becomes about the divergence in the code bases and reconciling them. If Vulcan really can't perform as it must to be used as the fundamental engine architecture of FB3, then the FB3 merger is about far more than resolving class name changes and updating the optimizer - it is about the guts of Vulcan and whether the sharing model really understands what is shared, when, and why.

8. Related to this has to be some kind of protocol for testing before a push. Threading issues are so hard to debug that they become exponentially harder to track down and repair the further they become buried in the CVS history records. If code is changed that could reasonable be expected to influence the thread-safety of the project, it must be tested against the approved benchmarks regularly and ideally before commit for large changes. It is bad enough when single threaded code is pushed without adequate validation, but it can be the death of a code base when those changes affect concurrency. You can take this any way you like, but too much of Vulcan has already been written without adequate testing. We are compounding the difficulty of retrofitting threading on a monolith by attempting to retrofit quality on the threading. Lots of this is due to the issues above involving availability of test environments and agreement on the requirements, but it's a problem
that will get worse - not better - as more folks get involved in modifying Vulcan.


WHAT DO WE NEED TO DO NEXT?

I don't want to start a flame war, and I sure don't want to retard forward progress on Vulcan. But I work with more than a few smart people, and our team couldn't make SHARED_CACHE work reliably after trying for quite a while, using the best tools and systems we had available. It is my sincere hope that this was largely because we at SAS are still learning the Firebird/Vulcan architecture, and if we had the kind of deep knowledge that many of you have, it would be a workable problem.

My point is that I think this is a big deal, and needs to be tackled before there is too much planning on a FB3 merger that will take away energy from the "does it really work" question. And that question needs independent validation, from parties other than either Jim or me.

The community needs a plan to tackle this, and some resources to do it.

1. A test scenario needs to be developed. There needs to be an assessment about a reasonable test server configuration, in terms of number of processors, CPU power, memory footprint, etc. And we need to understand the test case to be thrown at that server: number of clients, think time versus work time, read/write ratios, degree of sharing of indexes, tables, and databases, etc.

2. There needs to be a definition of a "successful" test case. This should include what must happen during the test run, and what must not happen during the test run.

3. There needs to be a thorough review of the test software itself. We don't want the test driver to contain implicit assumptions or limits that skew the test towards any particular outcome. The test should not be what just one company wants or needs, but should represent the community interest.

4. There needs to be a test configuration provided for an independent assessment, with an agreed upon build of the system and a validation that it meets the requirements set out in item #1 above.

5. The tests need to be published and the community needs to openly discuss what they mean and what influence they will have on FB3 planning and execution.



CONCLUSION

At the end of the day, SAS is just one of the members of this community - and a fledgling one at that. But we have some resources that we can use to help solve these problems, even though we do not have the full knowledge of Firebird internals.

More importantly, we think that the promise of Vulcan is valuable and good, but the current implementation is not getting the attention it needs to fulfill that promise. We can help, but only so far as our knowledge takes us. I believe that the community needs to pick up the issue of Vulcan's scalability and threading and make it the first priority of post-FB2 work. And we need to start with a dispassionate evaluation of what we have in Vulcan today.

I wrestled with whether this was a Firebird developer or architecture issue, but I have settled on the developer list - we have real problems with the real code already implemented, and need a plan of attack on how to fix it that is larger than assigning it to a core developer.

I look to the community for input on what to do next.


--
Tom Cole, Platform R&D, SAS Institute Inc.

sorry for slashdot-ing

My recent article, MySQL's response to Oracle's moves, was Slashdotted. We all know what that means.

Luckily I host in the US, with layeredtech. The site seemed to survive the onslaught, except for a few complaints that may have been about the stylesheets not loading.

http://www.greenman.co.za/b2evolution/blogs/index.php?p=267


..::::..

Smart moves by MySQL AB

Now there seems to be a clear response. MySQL has hired former Firebird developer Jim Starkey and MySQL has a new CTO: Taneli Otala - read Kaj Arnö's interview with Taneli.

The final statement on this interview declares a clear goal: "Definitely. I want to be part of the team building the world's best database!". The times when MySQL targeted itself mainly to drive small and medium web based applications are definitely over!

The fact that MySQL is hireing new developers is just another indication that underlines that MySQL is moving forward towards the "big competitors".

read more on db4free blog

..::::...:::..::::..

Saturday, March 04, 2006

php5 and firebird 1.5 on debian or ubuntu

Darren wrote (in firebird-php list)

Decided to install php5 and firebird 1.5 on Debain
very easy

do the following edit

# vi /etc/apt/sources.list

add these two lines to the file

deb http://people.debian.org/~dexter php5 sarge
deb-src http://people.debian.org/~dexter php5 sarge

save and exit :wq

then do a
# apt-get update

then install all the modules you need
use this command to check whats available
#apt-cache search php5

then install what you want
#apt-get install php5 php5.0-firebird

it installs a few things like apache etc if you havent already got it
installed.

then restart apache
/etc/init.d/apache2 start

you might want to remove php4 beforehand if you have it installed

it seems to work fine big thank you to the guy who maintains this
package! if you are on here. Debian ROCKS.

..::::..::::..::::..::::..::::..

Firebird logo - remineds me of mortalkombat.

Quote of the day " Also I love the logo, remineds me of mortalkombat."
..::::..

Thursday, March 02, 2006