Post a Comment
RE: I Hope It has more builtin functions
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.
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.>
[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.



.