Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

JDataStore is a deprecated feature

23 views
Skip to first unread message

Frintrop

unread,
Nov 10, 2005, 5:35:08 AM11/10/05
to
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 ?!?


Frintrop

unread,
Nov 10, 2005, 6:55:59 AM11/10/05
to
Hi,

I have called german Borlad Infocenter.

Jdatastore is running out of live !!!! You cannot buy any further support

"Frintrop" <em...@andrefrintrop.de> schrieb im Newsbeitrag
news:4373223e$1...@newsgroups.borland.com...

Thomas Pfister

unread,
Nov 10, 2005, 2:16:01 PM11/10/05
to
Andre,
congrat, you're one of the first who read the readme from the newest
JBuilder (btw the latest one, the next build is an AddOn from Ecclipse...)

JDataStore will not further develop by Borland :-(

Change to InterBase 7.5 or Oracle if you need the database an more operating
sytems...

Gruss

:-) thomas


"Frintrop" <em...@andrefrintrop.de> schrieb im Newsbeitrag
news:4373223e$1...@newsgroups.borland.com...

Mehmet Erten

unread,
Dec 7, 2005, 9:37:51 PM12/7/05
to
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.


Lori M Olson [TeamB]

unread,
Dec 8, 2005, 1:16:02 AM12/8/05
to

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.

Google Advanced Newsgroup Search
http://www.google.ca/advanced_group_search
Other Newsgroup Searches:
http://www.borland.com/newsgroups/ngsearch.html
Joi Ellis's FAQ-O-Matic:
http://www.visi.com/~gyles19/fom-serve/cache/1.html

Paul Furbacher [TeamB]

unread,
Dec 8, 2005, 2:22:18 AM12/8/05
to
> 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).


--


Paul Furbacher (TeamB)

Save time, search the archives:
http://info.borland.com/newsgroups/ngsearch.html

Is it in Joi Ellis's Faq-O-Matic?
http://www.visi.com/~gyles19/fom-serve/cache/1.html

Finally, please send responses to the newsgroup only.
That means, do not send email directly to me.
Thank you.

David Orriss, Jr. [TeamB]

unread,
Dec 13, 2005, 2:21:15 PM12/13/05
to
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.

My blog: http://mywebpages.comcast.net/daorriss/

Save yourself some time and check these sites:

Borland Newsgroup Search:
http://www.borland.com/newsgroups/ngsearch.html
Joi Ellis's Faq-O-Matic:
http://www.visi.com/~gyles19/fom-serve/cache/1.html

Paul Furbacher [TeamB]

unread,
Dec 13, 2005, 3:31:19 PM12/13/05
to
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.

I haven't used Firebird to any great extent.
John Moore may have more to say on it.

David Orriss, Jr. [TeamB]

unread,
Dec 27, 2005, 1:29:23 AM12/27/05
to
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.

Mehmet Erten

unread,
Jan 17, 2006, 10:35:03 PM1/17/06
to
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.

(Any new news from JDataStore)


Quinn Wildman

unread,
Jan 18, 2006, 11:24:32 AM1/18/06
to
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.

Paul Furbacher [TeamB]

unread,
Jan 18, 2006, 4:00:10 PM1/18/06
to
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.

Please don't do it here.

Thanks.

Bruce Alspaugh

unread,
Jan 25, 2006, 11:12:50 AM1/25/06
to
"Frintrop" <em...@andrefrintrop.de> wrote in message
news:4373223e$1...@newsgroups.borland.com...
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:

HSQLDB: http://hsqldb.org/
OneDollarDB: http://www.daffodildb.com/onedollardb-opensource.html (I'm
rather impressed by this one. Don't let the name fool you.)
Mckoi: http://mckoi.com/database/
Derby: http://db.apache.org/derby/

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?

http://firebird.sourceforge.net/


David Orriss, Jr. [TeamB]

unread,
Jan 25, 2006, 9:49:38 PM1/25/06
to
On Wed, 25 Jan 2006 10:12:50 -0600, Bruce Alspaugh wrote:

> Do we loose anything by going with one of
> these instead of JDataStore?
>

Performance/scalability. JDatastore is much faster than any of the others
you mentioned.

> 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?
>
> http://firebird.sourceforge.net/

I hope there is... Just have to wait and see.

John T. Dow

unread,
Jan 26, 2006, 10:07:29 AM1/26/06
to
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.

John

David Orriss, Jr. [TeamB] wrote:

Bruce Alspaugh

unread,
Jan 26, 2006, 10:08:15 AM1/26/06
to
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?

Bruce


Gillmer J. Derge [TeamB]

unread,
Jan 26, 2006, 10:26:13 AM1/26/06
to
David Orriss, Jr. [TeamB] wrote:
> On Wed, 25 Jan 2006 10:12:50 -0600, Bruce Alspaugh wrote:
>
>>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?
>>
>>http://firebird.sourceforge.net/
>
> I hope there is... Just have to wait and see.

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.

http://bdn.borland.com/article/0,1410,33064,00.html

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.

--
Gillmer J. Derge [TeamB]

Bruce Alspaugh

unread,
Jan 26, 2006, 10:33:02 AM1/26/06
to
"John T. Dow" <jo...@johntdow.com> wrote in message
news:43D8E5B1...@johntdow.com...

> 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.

Bruce


John T. Dow

unread,
Jan 27, 2006, 12:40:42 PM1/27/06
to
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.

0 new messages