I have found that in the release notes of jbuilder 2006 ( readme.html ):
JDataStore As of JBuilder 2006, JDataStore is a deprecated feature and should not be used except for legacy support or temporary development. You should use a different DBMS for deployment purposes.
>I have found that in the release notes of jbuilder 2006 ( readme.html ):
> JDataStore > As of JBuilder 2006, JDataStore is a deprecated feature and should not be > used except for legacy support or temporary development. You should use a > different DBMS for deployment purposes.
>I have found that in the release notes of jbuilder 2006 ( readme.html ):
> JDataStore > As of JBuilder 2006, JDataStore is a deprecated feature and should not be > used except for legacy support or temporary development. You should use a > different DBMS for deployment purposes.
It is still on Borland web to be sold. 7.03 came out recently. DB/2, Oracle on the one hand InterBase from Borland on the other hand. Which one is relatively painless both in JBuilder and performance/operation? Hopefully we will hear from the official people about this soon.
Mehmet Erten wrote: > It is still on Borland web to be sold. > 7.03 came out recently. > DB/2, Oracle on the one hand > InterBase from Borland on the other hand. > Which one is relatively painless both in JBuilder and performance/operation? > Hopefully we will hear from the official people about this soon.
And you think TeamB is "official people"? ;-) This thread was my first knowledge of the subject. Borland tends not to comment on such issues.
From personal knowledge, I must say that I would NOT recommend Oracle. It is a complicated nightmare to administer. I switched from Oracle to JDataStore mostly because JDataStore was so darn easy to use and administer.
--
Regards,
Lori Olson [TeamB]
------------
Save yourself, and everyone else, some time and search the newsgroups and the FAQ-O-Matic before posting your next question.
> Mehmet Erten wrote: >> It is still on Borland web to be sold. >> 7.03 came out recently. >> DB/2, Oracle on the one hand >> InterBase from Borland on the other hand. >> Which one is relatively painless both in JBuilder and >> performance/operation?
Oracle in the same breath as painless?! That's a new one.
Lori M Olson [TeamB] wrote:
> From personal knowledge, I must say that I would NOT recommend Oracle. > It is a complicated nightmare to administer. I switched from Oracle to > JDataStore mostly because JDataStore was so darn easy to use and > administer.
Ditto on the Oracle part. I recently moved a large Web app from Oracle to MySQL because Oracle kept corrupting its databases when the server crashed. How solid and reliable is that?! Recovering the databases was a painful process. In contrast, the MySQL databases running on the same machine never missed a beat because of the crashes. Also, its admin and browser tools are far superior to what Oracle offers (in my opinion, of course).
On Thu, 08 Dec 2005 02:22:18 -0500, Paul Furbacher [TeamB] wrote: > Recovering the databases was a painful process. > In contrast, the MySQL databases running on the same machine > never missed a beat because of the crashes. Also, its admin > and browser tools are far superior to what Oracle offers (in > my opinion, of course).
Continuing on in the free realm - how do you guys think IBPhoenix match up to MySql and to Interbase?
We use Derby (Cloudscape) in part of our product line (to handle some client-level caching of information while still maintaining a database format for the information). Derby is nice - but not nearly as nice as JDS - I don't care if it IS free... :P
Right now my choices would be to use MySql or IBPhoenix. Hopefully something comes along that's better in the Java-based landscape for databases that's free... ;)
-- David Orriss Jr. [TeamB] http://www.codethought.com * Please limit all responses to the newsgroups. Thanks! * The JBuilder Webring is dead - long live the JBuilder Webring.
On Tue, 13 Dec 2005 15:31:19 -0500, Paul Furbacher [TeamB] wrote: > David Orriss, Jr. [TeamB] wrote:
>> ...how do you guys think IBPhoenix match up >> to MySql and to Interbase?
> I think you mean Firebird. From what I > understand, IBPhoenix is a service organization > dedicated to Interbase and Firebird support.
Ah.. I think you may be right.
> I haven't used Firebird to any great extent. > John Moore may have more to say on it.
OK thanks.
-- David Orriss Jr. [TeamB] http://www.codethought.com * Please limit all responses to the newsgroups. Thanks! * The JBuilder Webring is dead - long live the JBuilder Webring.
So far I really like how to connect to JDataStore. Does Interbase work the same way with the remote connection? That's just to define the IP number and point to the database file. Interbase works with all Borland product as it is (that's what I understood from the introduction papers). It means ODBC and JDBC drivers are all embedded as native features which are really cool feature to integrate different applications with one database. Any interbase user's input will be appreciated.
You have a number of options of connecting to an InterBase database. If it is local, you can just point to the file. However, this is not inprocess like JDataStore. For a remote connection, you can generally use ipadress and filename and always use servername and filename. InterBase 7.5 also supports aliases, so can use ipadress and alias or servername and alias too. Finally netbui is supported too, so you can give a netbui name and filename too.
Note that our ODBC support is kind of in flux right now. The current version of InterBase includes only a trial ODBC driver. We are working on provided a full ODBC driver with InterBase 8.
If you have more questions in this regard you should post them to an interbase newsgroup.
Mehmet Erten wrote: > So far I really like how to connect to JDataStore. > Does Interbase work the same way with the remote connection? > That's just to define the IP number and point to the database file. > Interbase works with all Borland product as it is (that's what I understood > from the introduction papers). > It means ODBC and JDBC drivers are all embedded as native features which are > really cool feature to integrate different applications with one database. > Any interbase user's input will be appreciated.
Mehmet Erten wrote: > So far I really like how to connect to JDataStore. > Does Interbase work the same way with the remote connection?
> [...]
Please don't piggyback a new discussion on an old subject! If you have a new question, start a new thread. Piggybacking is something you can do on AOL while having a "me, too" moment.
>I have found that in the release notes of jbuilder 2006 ( readme.html ):
> JDataStore > As of JBuilder 2006, JDataStore is a deprecated feature and should not be > used except for legacy support or temporary development. You should use a > different DBMS for deployment purposes.
> Does anybody know what this means ?!?
Since JDataStore is deprecated, was there anything special that JDataStore offered feature-wise that other embedded Java DB's did not? There are lots of open-source embeddable pure Java DB's out there like:
And new ones coming out every day like (http://www.h2database.com/html/frame.html). I saw the article by Lori on how to use Derby with JBuilder. Do we loose anything by going with one of these instead of JDataStore?
Is there any chance Borland might open-source JDataStore like they did Firebird and let the community support it rather then just let it die?
-- David Orriss Jr. [TeamB] http://www.codethought.com * Please limit all responses to the newsgroups. Thanks! * The JBuilder Webring is dead - long live the JBuilder Webring.
I have been using JDataStore7 but recently looked around at others. I ruled some out as clearly inadequate. I've been working with Derby recently because it seemed more promising. However, performance does not seem to be equal to jds, as David writes. I'm seeing that in the time it takes to retrieve, even with indexed columns.
Another performance plus for jds: you don't have to use jdbc to access it, which gives you a big performance boost when importing or exporting large amounts of data.
Also, Derby is not nearly as powerful as jds. For example, you can't drop a column, you can't change a column type, I don't believe you can even rename a column. The only change you can make to an existing column is to make a varchar longer (but not shorter). Other than that, to make a change you'd have to add a new column, but then you can't get rid of the old one. JDataStore provides far more flexibility manipulating an existing table.
Has Borland published any benchmarks to back up the claim that JDataStore offers better performance than the others? The benchmarks for JDBC/HSQLDB looked pretty good on PolePosition: www.polepos.org
Apparently, a JDataStore can be used as a persistent backing store for cached rows instead of keeping them in memory. I gather this is useful if you have a large number of objects from a remote DB, or have a laptop user who can work remotely and then sync up their changes when they are back at the office network. Is it possible to use a different DB in this role?
For what it's worth, we're still using JDataStore for EventCentral (http://ec.borland.com). I haven't been told to switch to another database, so I take that to mean there's at least some hope remaining for a resurrection.
Regarding performance, there are some benchmark results in the article referenced below. It doesn't directly compare the results with other implementations, but you could probably do those tests yourself if you wanted to. Either way, it shows good performance and scalability.
That article reminded me of what I think is another big advantage of JDataStore over HSQL and Derby. Those don't support mirroring and automatic failover, do they? That's not really important in many embedded database applications, but it does make JDataStore a much more serious and capable entry in the field.
> Also, Derby is not nearly as powerful as jds. For example, you can't drop > a column, you can't change a column type, I don't believe you can even > rename a column. The only change you can make to an existing column is to > make a varchar longer (but not shorter). Other than that, to make a change > you'd have to add a new column, but then you can't get rid of the old one. > JDataStore provides far more flexibility manipulating an existing table.
Does Derby not support the ALTER TABLE statement? I've been using HSQLDB lately. According to pp. 87-88 of the HSQLDB User's Guide, it supports adding, dropping and renaming columns. You can also add and drop constraints and indexes. It also looks like you can change the datatypes when the individual existing values can be converted.
It provides limited support for ALTER TABLE. Here's a quote from the manual showing how you can alter existing columns.
John
Modifying columns
The column-alteration allows you to alter the named column in the following ways:
• Increasing the length of an existing VARCHAR column.
CHARACTER VARYING or CHAR VARYING can be used as synonyms for the VARCHAR keyword. To increase the width of a column of these types, specify the data type and new size after the column name. You are not allowed to decrease the width or to change the data type. You are not allowed to increase the width of a column that is part of a primary or unique key referenced by a foreign key constraint or that is part of a foreign key constraint.
• Specifying the interval between consecutive values of the identity column.
To set an interval between consecutive values of the identity column, specify the integer-constant. You must previously define the column with the IDENTITY attribute (SQLSTATE 42837). If there are existing rows in the table, the values in the column for which the SET INCREMENT default was added do not change.
>>Also, Derby is not nearly as powerful as jds. For example, you can't drop >>a column, you can't change a column type, I don't believe you can even >>rename a column. The only change you can make to an existing column is to >>make a varchar longer (but not shorter). Other than that, to make a change >>you'd have to add a new column, but then you can't get rid of the old one. >>JDataStore provides far more flexibility manipulating an existing table.
> Does Derby not support the ALTER TABLE statement? I've been using HSQLDB > lately. According to pp. 87-88 of the HSQLDB User's Guide, it supports > adding, dropping and renaming columns. You can also add and drop > constraints and indexes. It also looks like you can change the datatypes > when the individual existing values can be converted.
