We want your feedback about InterBase

Posted by on in Blogs

During the last few months we have been having a lot of discussion about InterBase.  Since version 7 InterBase has come out with important features like: InterBase Performance Monitor, Batch Updates, Journaling Incremental Backup, SMP support and others.

Developers Matter at CodeGear, so I really want to know your feedback about InterBase and how we can make InterBase better.

Please, This email address is being protected from spambots. You need JavaScript enabled to view it. your opinion about InterBase.

Versão em Português clique aqui
Versión en Español clic aca



Comments

  • Guest
    Interbase User Saturday, 5 May 2007

    It would be nice to have replication

  • Guest
    Filip Demuynck Sunday, 6 May 2007

    Make it cheaper for a licence, distribute it as a download and i'll switch back to Interbase from Firebird.

    I develop mostly for smaller companies and Firebird does all i need perfectly well. (+ its free). Charge for support or for the big iron but for a lot of developpers there are plenty of alternatives (MySQL, Firebird...etc) that are freely available and instatly downloadable.

    I would defenitely switch back if the price and/or deployment restrictions drop.

  • Guest
    Zenon Sunday, 6 May 2007

    Hi,



    What I would like to see implemented is

    exactly what is missing in Firebird i.e.



    * 64-bit support and utilization of

    multiprocessor servers with a huge amount

    of memory installed (>32GB)

    * tablespaces, it helps when performance is

    the paramount

    * replication



    As for marketing side I second to what Filip Demuynck wrote in his post above.

  • Guest
    Steven Summers Sunday, 6 May 2007

    I don't think it makes sense for CodeGear to continue to sell and develop InterBase independent of Firebird.



    Back when you were splitting off the tools division, it was clear that IB was in the category of programs that should have been retained by Borland, not taken over by CodeGear. Why Interbase but not AppServer or VisiBroker? Exactly how is Interbase a "developer tool"?



    Many of us are wondering why Borland didn't want Interbase, when it fit with that side of the business so much better. If it's profitable, why didn't they want it? And if it isn't, why does CodeGear want it?



    Selling a database engine while claiming that the developer tools are "independent" also strains your credibility. Wouldn't it make a lot more sense to keep your resources focused on BDS and JBuilder- your ACTUAL developer tools?



    Personally, I think it would make MUCH more sense to re-open-source Interbase- release all the post 6.0 code so it can be merged with Interbase (and Vulcan), keeping the best parts of each. Maybe contribute a developer or two to help with the effort, and continue to sell support for the combined product, just as you do now for Interbase.



    Sure, you'll loose some money on licenses, but how much can you be making, when you're competing with Free? Meanwhile, you're leaving money on the table by supporting IB but not Firebird- even though stats are showing that FB has about 2/3 of the combined customer base.

  • Guest
    Robert Love Monday, 7 May 2007

    Interbase is not big enough to handle the size of Data we have. So we use Oracle (Terabytes) I don't think we would even consider switching off Oracle as this point. The investment is too great.



    However, we have embeded local databases for some applications that were writen with Paradox that we have yet to convert to another Database. We would consider InterBase, but the pricing seems a bit high for this market as well.



    So overall I think your not in the High End or the Low End Systems, your in the middle. Your pricing reflects that but, does leave us out of the loop as potential customers.

  • Guest
    Chad Monday, 7 May 2007

    Is it possible that we have technologically moved WAY FORWARD from the 1980s when SQL databases were the 'cutting edge' of technology? I mean SQL databases are now just 'assumed' and for the most part, FREE. Speaking personally, I can't handle the extortionary approaches of many software companies in charging runtime license fees to deploy software that I already purchased a license for. Such is the case with Delphi. I pay for a development license - I deploy my work freely. That's great. Why is it not that databases don't work the same way?

  • Guest
    SQL = Miami Vice Monday, 7 May 2007

    Firebird is free, embedded or server options, lots of ported platforms supported, a great support user community, and it rocks. Period. I agree with Chad - it isn't the 80s anymore when databases ruled. Let's move on. SQL should be free, and let's innovate in new areas.

  • Guest
    Andrew Monday, 7 May 2007

    - embedded server like firebird

    - GUI for "ibconfig"!

    - higher default values for lock buffer (I always tripple them), memory buffer, sort mem, etc

    - or wizard style for selecting usage: light+some users or heavy+many users

    - hints about or auto optimizing (indexes, but also why is a query slow (mem, disk, cpu, index, etc)

    - more statistics about server performance (mem, disk, cpu)

    - be able to log query statistics (plan, execution time, etc). IBConsole Performance Monitor only shows snapshot of currently running queries. Now, you cannot easy determine why an attachment is slow/heavy.

    - greater memory buffer. On a 4GB server, only 1GB(?) is used.

  • Guest
    Markus Venter Wednesday, 9 May 2007

    FB easily handles up to 50 concurrent users. Why use IB for small to medium companies? It is as if Codegear is now trying to protect the once brilliant piece of technology (and it still is) against similar free alternatives. Being developer focused, you should look at what M$ is doing with SQL Server and start following or bettering their offering.



    I understand why you want interbase, but then I agree with Steven Summers above. Start supporting / working WITH the FB team and not against them. Thereby allowing yourselves to compete with M$. Many small companies do not care about which DB they use - as long as the job gets done. When they grow, the requirements changes.



    So this is my position:

    I develop a small system using FB (It's Free).

    My client grows.

    I introduce a server architechture in the form of M$ SBS.

    I get a database server with the package (M$ SBS premium with SQL Server)

    How do I sell Interbase?

    I port my application to SQL Server and all I need to do is buy CALS for new users.



    My options:

    1.) Develop my customer's system on SQL Server from the start.

    2.) Use FB and believe they do not outgrow the capabilities.



    Start thinking out of the box re. your marketing strategy in comparison with the Redmond Giant.



    My suggestion if you are not thinking of open-sourcing IB:

    1.) Work closer with FB and your tools division to provide support for both IB AND FB.

    2.) Make your money on supporting FB and selling licences for IB where required.

    3.) Start supporting FB in your DEV tools. That will help us to upsell to IB!

    4.) Make sure that IB is indeed a better product than FB.



    I believe that you should not ignore the presence of FB and it's popularity.

  • Guest
    Andrew Wednesday, 9 May 2007

    - cheap support for dual cores

    - sql: sub select as tables like Oracle

    (select t.*

    from (select * from table where id > 0) t

    where t.id > 1)

    - some kind of service helper for easier/better showing the status of ibserver (instead of reading interbase.log) in case of errors etc

    - redesign tools for more professional looking

  • Guest
    John Wednesday, 9 May 2007

    I have to disagree, FB not handle very well concurrent users, special if you have more than 30 concurrent users.



    I use FB in small customers, less than 10 users - customer where I have more then 20 concurrent user and the application is critical mission I'm using IB.



    But I want to see in IB:



    - Better InterBase price

    - Better GUI for database management

    - Improve the query optimizer

    - Win64 support, really important

    - sub select

  • Guest
    Daniel Thursday, 10 May 2007

    I agree with most of the comments, I want to add:



    - Work closer to FB and offer whatever they do at least. Don't diverge features.

    - Graphical tool for administration, queries, live profiling and tracing, datamodeler, import / export. (think of SQL Server Enterprise Manager + Query Analizer + Profiler).

    - The Data Modeler should be able to get diagram from database, sinchronize with database, and import models from another databases (to ease migrations to IB). Not the crappy SQL Server "Diagrams", something powerful like Erwin or Case Studio.

  • Guest
    Jose Luis Rocha Thursday, 10 May 2007

    **** 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">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

  • Guest
    Tom Wilk Wednesday, 16 May 2007

    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

  • Guest
    Maxim Shiryaev Wednesday, 16 May 2007

    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.

  • Guest
    mark Ellis Wednesday, 16 May 2007

    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

  • Guest
    m. Th. Thursday, 17 May 2007

    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.

  • Guest
    Paul Maliphant Sunday, 20 May 2007

    Drop it.

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

  • Guest
    Lester Caine Sunday, 20 May 2007

    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.

  • Guest
    Mark Monday, 21 May 2007

    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.

  • Please login first in order for you to submit comments

Check out more tips and tricks in this development video: