The Firebird Project is pleased to announce the release of Firebird 2.0 Beta 1 kits for immediate download and testing. This version of Firebird 2 is an beta version, meant for field testing only and not for use in production. Please read the Release Notes for more details.
Firebird 2.0 Beta Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
last i heard firebird was at 1.5. What happened to deerpark?
I tried Firebird 1.5 awhile ago and I was shocked how many builtin SQL functions that I’d learned to take for granted with MySQL/Postgres were not there. I *believe* some of the missing ones had to do with date/datetime datatypes. Anyway, I hope they have improved on that.
Jesus, is it you that always spouts this crap every timt there is a Firebird story?
As previously explained… anything you need can be written as a UDF. And, NO, writinf UDF is a piece of cake in Delphi. And before you scream “but a UDF isn’t native functions”, how the hell do you think MySQL et al provide the functions you believe are missing? Through the same mechanism – whether the functions are hard coded into the server or in a plug-in, it the same freaking principal!!!
Aren’t we still waiting on 1.5 to be released?
Firebird 2.0 is a database, not a browser.
This is not Sunbird either. I thought oooh the new version of the mozilla calendar app. Mistaken.
Previously known as, “Interbase”.
No, still known as Interbase. Firebird is a fork of the ill though out opensource fiasco Borland had around the time of Interbase 6.
Nope, they still want you to use UDFs for that kind of stuff, they also still don’t have temp tables.
Your better off sticking with Postgresql, it’s by far the best Open Source Database available.
From what I have read they won’t be implementing built in functions until FB 3.x which is a long long long way off.
We will be lucky to se FB 2.0 by April 2006.
Postgresql is just a joy to work with compared to FB
As previously mentioned last time there was a Firebird thread on OSNews… YOU DON”T NEED TEMP TABLES because Firebird and Interbase have a far simple mechanism for achieving the same result.
create procedure test()
returns (avalue integer)
as
begin
for select myvalue from atable where myid > 10 and myid < 100 into :avalue do suspend;
end
Et voila, a temp dataset.
LOL man!.
Good luck finding a DBA job, heh. If you don’t know what’s the difference between a temp dataset and a temp table, well … go and read something
.
Beta?
I thought it would be ready for late November?
I like FB but its developing is to slow.
and still do, but development does seem to be slowing down. I hope they don’t get too far behind.
A temp dataset is not the same thing as a temp table.
Please stop saying it is, IT IS NOT THE SAME THING.
A temp table stays persistant through the connection or transaction and is dropped automaticly when the connection or transaction ends. Lets see, all the big iron servers like Oracle,DB2 and even MS SQL server have them…..I wonder why….
Also I know full well that writing a UDF is pretty easy with Delphi/Kylix(when I was a firebird user I wrote my own all the time), the point is I should not have to write a UDF for common functions that should be built in.
A UDF must be installed in each and every database you create in Firebird, it’s just a pain in the ass, and Delphi UDFs will only work on win32 or Linux, with Postgresql since anything you could ever want is built in there is no issue in moving your database to any other platform. With postgres I can simply restore my database on BSD,AIX,Solaris etc and it will just work, I don’t have to fool around with finding a compatible UDF. That’s what the big deal is..
Just face it people Firebird is not Enterprise Class software yet!!!! It’s missing tons of features and has very poor documentation.
Just face the facts and start using something better, that’s what I did, i used to be a big time Firebird user until I saw the light and moved everything to Postgresql.
> A temp dataset is not the same thing as a temp
> table. Please stop saying it is, IT IS NOT THE
> SAME THING.
Um, for all intents any purposes, yes it is the same thing. A temp table is, by definition, read only. If you write data to a temp table, it’s hardly really a temp table, its then going into the realms of poor design.
> A temp table stays persistant through the connection
> or transaction and is dropped automaticly when the
> connection or transaction ends.
As does a stored proc. It stays prepared until you unprepare it.
The interbase way of doing things is just different.
Oh, and on a final note: Interbase 7.5 HAS TEMP TABLES. It was one of the feature added, along with the ability to run multiple servers on the same machine. With Firebird, unfartunately, you get what you pay for. If you paid for Interbase, then a lot of your pathetic pickings are gone.
> Also I know full well that writing a UDF is pretty
> easy with Delphi/Kylix(when I was a firebird user I
> wrote my own all the time), the point is I should
> not have to write a UDF for common functions that
> should be built in.
Why? I have never needed anything much past Free UDF lib, and I have been working with Interbase and Firebird for years in realtime fleet management software.
> A UDF must be installed in each and every database
> you create in Firebird, it’s just a pain in the ass,
That is complete crap. You need to install the UDF on the machine running the server. End of story. Well, unless my 100 or so clients with on average 5 user are all defying your claim by some kind of magic.
> and Delphi UDFs will only work on win32 or Linux,
> with Postgresql since anything you could ever want
> is built in there is no issue in moving your
> database to any other platform. With postgres I can
> simply restore my database on BSD,AIX,Solaris etc
> and it will just work, I don’t have to fool around
> with finding a compatible UDF. That’s what the big
> deal is..
Write your UDF in C then. Jaysus, its just another excuse. If you really need to support platforms outside of the 90% of most corperate users, then more fool you.
> Just face it people Firebird is not Enterprise Class
> software yet!!!!
Totally agreed, which is why we still use Interbase.
> Just face the facts and start using something
> better, that’s what I did, i used to be a big time
> Firebird user until I saw the light and moved
> everything to Postgresql.
All you using Postresql tells me is “I’m too cheap to buy a Enterprise level RDBMS”. If you were totally serious about performance etc, you’d be using Oracle, and if you wanted to conform, you’d be using SQL Server. Face it, you want corperate/enterprise performance, but you’re not willing to stump up the cash to get it.
You have just demostrated how to have a procedure return a read only result set, not even close to the same thing as a temp table. Like mentioned before a temp table is a real table and is not read only and can persist through a connection or a transaction and is automaticly dropped.
You need to get your facts straight bucko…
<As previously mentioned last time there was a Firebird thread on OSNews… YOU DON”T NEED TEMP TABLES because Firebird and Interbase have a far simple mechanism for achieving the same result.
create procedure test()
returns (avalue integer)
as
begin
for select myvalue from atable where myid > 10 and myid < 100 into :avalue do suspend;
end
Et voila, a temp dataset.>
It’s not crap buddy, it’s cold hard facts.
I am really sorry you have trouble dealing with this.
get over it and move on…
And you don’t have to call me Jesus, I am not the savior of the world, just of poor souls stuck using Firebird.
the flamewars have 🙂
I love it how these people think that a function or proc returning a result set can do the same thing a temp table can do.
[QUOTE]
> A temp dataset is not the same thing as a temp
> table. Please stop saying it is, IT IS NOT THE
> SAME THING.
Um, for all intents any purposes, yes it is the same thing. A temp table is, by definition, read only. If you write data to a temp table, it’s hardly really a temp table, its then going into the realms of poor design.
[/QUOTE]
I have many times needed a 1st class citizen temp table and then updated data on it. Mostly have done some complex stored procedure code and at the end of it returned a resultset. I can fine link temp table to real tables in a final resultset query.
MSSQL server is good at that part, I can return resultset from SPs and client apps see it as a normal query result. They can use rs=statement.executeQuery(sql) “select * from table” or “execute prDoTheThing” query transparently, I dont need to change anything at client side. Well, not at least when using JDBC drivers.