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 ?!?
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...
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...
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
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.
> 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
> ...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] 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.
(Any new news from JDataStore)
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.
> 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.
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/
> 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.
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:
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
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]
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
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.