Comments on: We want your feedback about InterBase

By: Markus Venter

Markus Venter — Tue, 22 May 2007 11:26:44 +0000

Had you embraced your original decision of open-sourcing IB, you would've had a much stronger product in the market. Other open source RDMS's have been playing catch up for a long time with FB.

If you continue riding on the (ever deminishing) wave of success like Borland has done with Delphi vs Visual Studio, you will inevitably find FB walking over IB like VS has captured the Dev Tools market.

Look at the easy upgrade path from other vendors and try and sell my customers IB. Hardware cost has not been an issue in the SMME market for a long time now. Small footprints no longer sell software.

Forget investing Million$$$$$ into IB. Throw some resources into merging with FB. Throw those million$$$$ into Dev tools like BDS and marketing and help us by giving us the market so that we can continue to support Codegear.

By: Doug Chamberlin

Doug Chamberlin — Mon, 21 May 2007 10:40:58 +0000

I agree with the general sentiments that Interbase’s days are over. Too expensive compared to alternatives. Not especially a stand-out compared to alternatives.

Perhaps morph it into a really, really good persistence store for objects. That or drop it altogether.

By: Mark

Mark — Mon, 21 May 2007 08:48:39 +0000

I think it would be a smart and strategic goal of CodeGear to forget any past history regarding open sourcing of Interbase (ie. Firebird) and just partner with FB. I’m sure FB could really use the support and I’m sure CodeGear would definitely find a better return on investment to partner with FB than pouring $$$$ into Interbase development when you have the level of product allegiance with FB as demonstrated by these posts.

By: Lester Caine

Lester Caine — Mon, 21 May 2007 02:22:00 +0000

I’m having enough trouble GIVING Firebird away when customers are so ham tied by agreements with M$ and Oracle. All my code HAS to be cross database simply to survive, so do I really need to worry about IB? I’ve still got 5.x licences on the shelf which will never be used.

JBuilder has gone Eclipse - D4PHP as an alternative for Zend’s late entry into Eclipse running as an alternative, and then expand the Eclipse tool base with some useful stuff.

Interbase does not give me anything that Firebird is not already supplying in my market place.

By: Paul Maliphant

Paul Maliphant — Mon, 21 May 2007 02:06:16 +0000

Drop it.

Focus on releasing products that work out of the box - not like D8..D2005 and D4PHP

By: m. Th.

m. Th. — Fri, 18 May 2007 00:40:06 +0000

I agree with the general opinion that, for your sake (and for community sake) you must incorporate IB features in FB (and _not_ FB in IB) ie. make one *free* product and support it. Also with developers and integration in IDEs (Delphi, C++, JBuilder, D4Php, CG Ruby IDE) but also with certification. Let’s call FB the free version and IB the closed, ‘certified’ version - something what achieved RedHat with its FedoraCore. But, frankly, I don’t know how many users will choose the ‘certified’ version, so IMHO don’t spend to much resources in that direction. Much more critical is to have an application-centric SQL server with embbeded version, SMP and all the features which are now scattered between FB and IB. This will be a very powerfull data backend for CodeGear’s suite of IDEs giving an advantage over MS which is hard to beat (if not impossible - I’m thinking now mainly at crossplatform issues and how deployable FB is - MsSQL needs (and installs) 50 MB runtime while FB is a few MB files copy). I don’t see any reason for IB to continue. IMHO, the game (or the war?) is (already) over. Open the DB backend and focus on your IDEs in order not to loose all.

HTH.

By: mark Ellis

mark Ellis — Thu, 17 May 2007 05:20:39 +0000

FB is the best i agree that working with the fb comunity and creating both a better DB admin IDE and Dataset components would be the best way to make some money and stay inovative, making them cross platform would add a huge Plus to codegear

By: Maxim Shiryaev

Maxim Shiryaev — Wed, 16 May 2007 23:54:51 +0000

IMHO, IB should do the same as JBuilder have done.
IB on top of FB like JB on top of Eclipse.

The only missing thing in FB is SMP support. But when we run 64bit platforms and have almost free (inexpensive) RAM the classic FB is OK.
In all other aspects FB is better.

Provide an IDE, replication, etc. And name it IB. Not a product, but an integrated solution. But it can be difficult to comtete IBExpert in IDE though.

Personally I will not go back to IB from FB if it don't supprt all FB 2.1 features and cannot handle 200+ concurrent connections.

By: Tom Wilk

Tom Wilk — Wed, 16 May 2007 19:50:29 +0000

YOU WILL EVENTUALLY BE FORCED TO EMBRACE FIREBIRD
=================================================
1. Firebird is the elephant in the room. If you ignore it, you will eventually get trampled by it. As soon as the Firebird team gets good SMP support you may get crushed.

2. Higher scalability and performance is the number one reason for using InterBase over Firebird (reliability is number two). To continue to sell InterBase as a separate product from Firebird, you MUST make it eXtremely scalable. Go BIG or go out of business. Go after MS SQL and Oracle in terms scalability and beat them on price. This means adding a much better optimizer and 64-bit support. Perhaps you could exploit Linux as a platform, as you have a better chance there. Beating M$ at Windows is probably impossible as they have the Windows source and you do not.

3. Firebird is going to appeal to open source developers and shops that make little applications that do not have scalability issues. To play on the low end you'll have to give InterBase away. You'll also have to add many of the same feature improvements found in Firebird 2.1.

4. Because in the long-run, there may not be allot of money in selling InterBase to the little guy, supporting Firebird as the entry-level InterBase might make allot of sense. Your potential customer base can only get bigger and you can then focus on the bigger VAR and enterprise customers by adding true enterprise features to Firebird.

5. At the least, add an InterBase/Firebird compatibility program to make sure that when the little guy outgrows Firebird, you've got him covered.

6. Many of the new features in Firebird 2.1 make allot of sense, so its probably time to add them to InterBase or to merge the enterprise features of InterBase into Firebird and make the whole thing one product. Selling InterBase enterprise plug-ins for Firebird might also be a good long-term strategy.

Tom

By: Jose Luis Rocha

Jose Luis Rocha — Thu, 10 May 2007 07:30:21 +0000

**** Problems / Improvements that could make life easier for programmers:

1. InterBase 2007 Price vs InterBase 6 / Firebird

We are currently using Interbase 2007 in our company. But we can not use it in our software in small companies because of its too high price.

So we distribute our software with Interbase 6. It means a lower performance compared to Interbase 2007, and that we can not use Interbase 2007 advance features and to take advantage of new hardware.

If this problem is not solved, our only alternative will be Firebird.

2. Performance problems

In certain cases, queries can be slow.

3. Lack of basic functionality in trigger and stored procedures language

It is difficult to implement some basic algorithms in triggers and stored procedures because of the lack of basic functions (trim, righttrim, etc.) in the language, without using User Defined Functions.

We avoid using UDFs in our applications, as we do with any other factor that can complicate the installation process or that can be a portability problem between distinct operating systems or hardware.

4. Queries can return an unexpected field

If a query has an unqualified field name that exists in several of the query tables, InterBase does not raise an exception or a hint, and the error can be undetected.

5. Make easier the debugging of data-driven algorithms from Delphi IDE

It's not easy to debug a data-driven algorithm in Delphi.

**** Possible solutions

1. Embedded version (dll or linkable .dcu) + unlimited runtime at low price.

In my opinion, an embedded version is essential (an external dll, or a .directly linkable dcu in Delphi executables), with a low cost.

The new version would have to use the license model of the programming languages (Delphi, etc): Programmer gets the licence at a relatively low price (for example, the current Delphi Professional price), with the possibility of an unlimited distribution of the dll in his software.

The idea is to open a new market for Interbase, the one needed by programmers who need to distribute the database with his own software, without affecting the sales of the current "Server" version of InterBase which is targeted to other markets/users/installations with much higher requirements.

Currently, it is obvious that such programmers don't buy InterBase, because of its too high price compared to FireBird and InterBase 6.

And this is difficult: to define what features the Embedded version must have, compared to the Server one, in order to open a new market for the Embedded version without affecting the sales of the Server one.

For example, it could have a limited maximum databases size, and perhaps a limited maximum number of concurrent connections, and use only one CPU. It would not have to include the more advanced features like Journaling, point in time recovery, online dump, etc.

2. Improvements in query optimizer and 64-bits version.

The query optimizer should be improved, specially in tables with compound indexes.

Release a 64-bit InterBase version that can take advantage of more than 2 Gb RAM.

3. Include some basic functions in the language without having to use udfs

We avoid using UDFs in our applications, as we do with any other factor that can complicate the installation process or that can be a portability problem between distinct operating systems and hardware.

The udfs of the library ib_udf could be included in Interbase. The costs and risks of doing this would be very low.

4. Possibility of raising an exception if a query has an unqualified field name that exists in several tables

For backward compatibility it must be optional (False by default).

Activating this option we would be able to detect logical errors in our aplications caused by this problem.

5. Make easier the debugging of data-driven algorithms from Delphi IDE

See QC# 20010

http://qc.borland.com/wc/qcmain.aspx?d=20010

**** My Priorities

1. Embedded version + unlimited runtime at low price
2. Query optimization
3. 64-bits InterBase
4. Make easier the debugging of data-driven algorithms from Delphi IDE (QC 20010)

Regards