Re: using ij in an ant task to create a database and nothing else
On Fri, Jun 12, 2009 at 5:04 PM, Kathey Marsdenkmarsdende...@sbcglobal.net wrote: Someone asked me today how to create a database with ij in an ant task by just using ij.database if they don't have any script to execute. He had implemented the following workaround to create a temporary file with just quit; in it. What about using Ant's sql task? I checked and this created the database without needing to touch any files: sql driver=org.apache.derby. url=jdbc:derby:mydb;create=true userid= password= set schema app; /sql It requires that you have *some* sql in there, so a set schema works nicely. andrew
Re: R: Using derby to parse an SQL statement
On Fri, Nov 14, 2008 at 6:15 AM, Rick Hillegas [EMAIL PROTECTED] wrote: Hi Flavio, I don't think that we have a good primer on the AST nodes. However, you can get some sense of what the nodes mean by building the Derby javadoc and looking at the javadoc for the package org.apache.derby.impl.sql.compile. The engine javadoc is also available online: http://db.apache.org/derby/javadoc/engine/ cheers, andrew
Re: Most efficient way to get max row id?
On Sun, Oct 19, 2008 at 1:52 PM, Amir Michail [EMAIL PROTECTED] wrote: Hi, I was wondering what is the most efficient way to get the max automatically generated row id. select max(...) is slow. If this is an identity column, perhaps IDENTITY_VAL_LOCAL() suits your needs? http://db.apache.org/derby/docs/10.4/ref/rrefidentityvallocal.html andrew
Re: URL Issue In Derby10.3.3.0 Download Page
2008/8/15 Qi Yun Liu [EMAIL PROTECTED]: Hi, When accessing the Derby10.3.3.0 Download Page, I find that the url of derby_ui_plugin_1.1.2.zip can not be opened.I use http://apache.mirror.phpchina.com. I am in Beijing, China. Thank you for the report. The link was pointing to the incorrect filename, it should have been derby_ui_plugin_1.1.1.zip. I have fixed the link and updated the website. The website takes an hour or two to refresh. In the meantime, you can download the UI plugin from here: http://apache.mirror.phpchina.com/db/derby/db-derby-10.3.3.0/derby_ui_plugin_1.1.1.zip Best regards, andrew
[ANNOUNCE] Apache Derby 10.3.3.0 released
The Apache Derby project is pleased to announce an important maintenance release of Derby, 10.3.3.0. Apache Derby is a subproject of the Apache DB project. Derby is a pure Java relational database engine which conforms to the ISO/ANSI SQL and JDBC standards. Derby aims to be easy for developers and end-users to work with. IMPORTANT NOTICE: If you are currently using Derby 10.3.1.4 or Derby 10.3.2.1, it is strongly recommended that you upgrade to Derby 10.4.1.3 or 10.3.3.0 to avoid any chance of database corruption due to an issue with multiple threads accessing a database that is documented in DERBY-3347. This bug can cause unrecoverable database corruption during periods of heavy, multi-thread I/O operations. The error produced in the test case used to diagnose the problem was: ERROR XSDB3: Container information cannot change once written: was 0, now 80. It is felt that other errors might also be generated when this type of corruption occurs. The corruption message will most likely refer to page 0 of the container. For example: ERROR XSDG1: Page Page(0 ,Container(0, 5856)) could not be written... This bug corrupts the pages on disk and can go unnoticed. If you do not run database consistency checks regularly it is recommended you begin doing so as soon as possible after the upgrade. To insure that corruption has not already occurred in existing databases, after upgrade run the database consistency check at least once to validate all tables in the database. This process is documented at: http://wiki.apache.org/db-derby/DatabaseConsistencyCheck If the corruption has already occurred there is no guaranteed recovery of data other than to recover from the last good backup. When doing so one should also check that the previous backup did not also have the corruption. In some cases one may recover data from the existing database, depending on the extent of the corruption, but will require by hand data recovery. Depending on the type of corruption this may be successful or not. one should consult the Derby list if attempting this recovery - no automatic software solution to this recovery exists. Version 10.3.3.0 can be downloaded from: http://db.apache.org/derby/releases/release-10.3.3.0.cgi Version 10.4.1.3 can be downloaded from: http://db.apache.org/derby/releases/release-10.4.1.3.cgi For help or questions, please post to the Derby User list. For instructions on how to subcribe and post to the Derby User list, please see: http://db.apache.org/derby/derby_mail.html
Re: Feedback releases/release-10.4.1.3.html
On Mon, Apr 28, 2008 at 1:09 PM, ted lifset [EMAIL PROTECTED] wrote: To Whom It May Concern: the page/section: http://db.apache.org/derby/releases/release-10.4.1.3.cgi#Distributions contains a link to: derby_core_plugin_10.4.1.648739.zip this file does not appear to exist on any mirrors. Dyre, I hope you don't mind, I went ahead and copied the core plugin files from the RC directory in your home dir over to the distribution location so that it gets picked up by the mirrors. andrew
Re: remote network server - connection refused
On 8/6/07, John Embretsen [EMAIL PROTECTED] wrote: I believe startNetworkServer (or any of the other scripts) does not pass any options you specify on the command line along to the network server, which means that the -h option you specified is ignored, and your server will only listen on the local loopback interface. Actually, it's only startNetworkServer and stopNetworkServer that don't pass additional arguments on to NetworkServerControl. It would be simple to fix this, by adding $@ to the shell script versions and %DERBY_CMD_LINE_ARGS% to the batch versions to the lines with the NetworkServerControl command. I've made this change with revision 563340.
Re: User/password encryption and deployment
On 6/15/07, Bill Shannon [EMAIL PROTECTED] wrote: I think the idea is to protect the communication between the client and the server so that passwords aren't sent in the clear. None of the data being stored in the database is being encrypted, just the client/server communication. It *is* 2007. Isn't this pretty much standard by now? See the discussion in http://issues.apache.org/jira/browse/DERBY-65 SSL is the recommended alternative to using the secure password protocol defined by the DRDA specification. Bernt Johnsen worked on this for 10.3, due out shortly, and it appears to be complete: https://issues.apache.org/jira/browse/DERBY-2108 andrew
Re: derby compile problem
On 4/24/07, Stanley Bradbury [EMAIL PROTECTED] wrote:
Hi
Check your ant build properties. I believe that this should be set to yes:
Proceed = no
Proceed should be set to no. The build shouldn't need to keep going
past any compile error to have a successful build.
Richard Pöttler wrote:
compile_iapi_jdbc_jsr169:
[javac] Compiling 10 source files to
/home/richi/temp/db-derby-10.2.2.0-src/classes
[javac]
/home/richi/temp/db-derby-10.2.2.0-src/java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java:94:
org.apache.derby.impl.jdbc.EmbedConnection is not abstract and does not override
abstract method setSavepoint(java.lang.String) in java.sql.Connection
[javac] public class EmbedConnection implements EngineConnection
[javac]^
[javac] 1 error
Could anyone help me please or point me in the direction how to get the
compilation working?
I would expect to see this error if you have set
'compile.classpath=${java14compile.classpath}' in your
~/ant.properties.
Please make sure that you have not set compile.classpath anywhere. If
you are not attempting to compile the JSR169 classes, then
compile.classpath should automatically be set to equal
${java13compile.classpath} in
tools/ant/properties/compilepath.properties.
HTH,
andrew
Re: Errors hen building derby using eclipse
On 4/19/07, Dimple Bhatia [EMAIL PROTECTED] wrote: Hi Andrew, I did follow the instructions in BUILDING.txt in the 10.2 branch which i am trying to build. Here are the content sof my ant.properties j14lib=c:/myddrive/J2Se1.4/jre/lib j13lib=c:/myddrive/jdk1.3/jre/lib proceed=true I am notsure whether the IBM JVM is being used but i tried to add the java14compileclasspth tot he properties file and that did not help either. Fromt he compile errors, it looks like it doesn't find the classes in the JCE. I have palced those jarsin %derbsource%/tools/javaas per the instructions in BUILDING.txt I don't see the classpath being set to %derbsource%/tools/java So I don't understand how it will find it. I also tried to build the source in the workspace from the command line using ant all but i see the same errors. Any other suggestions? The Derby build sets a number of properties that point to various jar files and resources by reading in several properties files from tools/ant/properties. If for some reason Ant cannot find the JCE jar in tools/java/jce1_2_2.jar, as specified in tools/ant/properties/compilepath.properties, you can try overriding that setting by adding 'jce1_2_1=/full/path/to/jce1_2_2.jar' in your ~/ant.properties. HTH, andrew
Re: Errors hen building derby using eclipse
On 4/18/07, Dimple Bhatia [EMAIL PROTECTED] wrote: Hi, I am tryin to build the derby source using eclipse. I am using this link i found on the derby wiki - http://wiki.apache.org/db-derby/BuildingDerby#head-0c0abaf557bc2cfe0efdbdd9a6098de1db0f6bb2 I have followed the instructions in building.txt but when I build i see a lot of errors such as below: I tried to add the jce1_2_2.ajr, junit.jar and jdbc2_0-stdext.jar as extnal jars to the project libraries under java build path but still the same problem. I am using the Ant builder asper the istrauctions on the above website. I woudl appreciate your hints. The classpath for the build is not determined by Eclipse's Java Build Path when building inside Eclipse using a custom Ant Builder. Several Ant properties need to be set in your ~/ant.properties file or loaded with Ant's -propertyfile option. See the file BUILDING.txt that is included in your checkout of the Derby source tree for more information about how to set these properties. The brief version is: * If you are building the trunk, make sure that j14lib is set to the location of a JDK 1.4 installation's 'jre/lib' directory in your ~/ant.properties and that you can build from the command-line using Ant. * If you are building one of the branches, be sure to follow all of the instructions in BUILDING.txt included with the branch and make sure that you have at least the j13lib and j14lib properties set in your ~/ant.properties. * If you are using an IBM JVM, be sure to follow the instructions in section 3.2.2 of BUILDING.txt regarding the setting of the java14compile.classpath property. HTH, andrew
Re: Setting the environment variables for Derby
On 3/28/07, Laura Stewart [EMAIL PROTECTED] wrote:
I guess I was expecting
that I could run it from any directory... or do I need to add the
C:\Derby_10\db-derby-10.2.2.0-bin\bin directory to my PATH variable
before I can run it anywhere?
This is correct. This step is mentioned in the Getting Started Guide
in Setting up your environment, as step 3, although it relies on
DERBY_HOME being properly set.
Perhaps an improvement would be to instruct the user to execute
'$DERBY_HOME/bin/sysinfo,' or even just 'ls $DERBY_HOME/bin' ('dir
%DERBY_HOME%' on Windows) and confirming that it points to the
location of the scripts before adding $DERBY_HOME/bin to the path, in
order to make sure that DERBY_HOME has been set correctly.
andrew
Re: Setting the environment variables for Derby
On 3/28/07, Laura Stewart [EMAIL PROTECTED] wrote: On 3/28/07, John H. Embretsen [EMAIL PROTECTED] wrote: Correct, you need to add the bin directory to the PATH variable for it to work from anywhere. For example as described in the Getting Started guide, http://db.apache.org/derby/docs/10.2/getstart/tgssetupjavaenvir.html. Can you help me understand the last part of setting for the PATH. I understand the first part %DERBY_HOME%\bin; What I don't understand in the docs is the last part %PATH% If I already have DERBY_HOME set what does %PATH% do? That adds the current value of the PATH variable to the end of the new setting for the PATH variable. If you don't do this, then only the Derby scripts will be in your path, and other important and necessary system executables will not be in your path and thus will not be runnable in your shell environment. Not a very useful situation to be in, since the Derby scripts rely on some of those system executables and would not be runnable without access to them either. andrew
Re: Javdoc
On 3/20/07, Bill Slack [EMAIL PROTECTED] wrote: Thanks for your response Bryan, What I am looking for in particular is the javdoc for the package org.apache.derby.jdbc, which is a package on my classpath for a program that I am developing using JDK6.0 and Netbeans 5.5. I thought Derby's javadoc was included in JDK 6, but if not, you can find it on the Derby website. Here's the 10.2 javadoc: http://db.apache.org/derby/docs/10.2/publishedapi/ HTH, andrew
Re: Javdoc
On 3/20/07, Bill Slack [EMAIL PROTECTED] wrote: Thanks Andrew, I couldn' find the javdoc in my installation. Your link helps if I can't find a site to download from. The link you provided links to the .html files themselves, which I'll use failing all else. Bill The 10.2.2.0 -bin distribution includes the API javadoc, which you can download from the Derby website here: http://db.apache.org/derby/releases/release-10.2.2.0.cgi andrew
Re: Derby storage using Java Web Start PersistenceService API - is it doable?
On 3/16/07, David Van Couvering [EMAIL PROTECTED] wrote: Hi, Luigi. I looked at this once, and it really didn't seem that the API provided by the JWS persistence service was sufficient for the needs of Derby. But I didn't look too closely at it. For me demo needs, a popup was fine. What you'd have to do is provide a new implementation of the storage interface. Others on this list can give you better guidance than I about where to look and how to do this. I suspect this is not for the faint of heart... *But* - if you *did* do this and you were successful, this would be a Very Good Thing for Derby users (and Java developers) in general, and I highly recommend that you contribute your work into the Derby codeline. If he's interested, an example of an alternate implementation of the StorageFactory interface exists, the in-memory storage factory attached to DERBY-646: http://issues.apache.org/jira/browse/DERBY-646 That might provide some guidance towards getting a JNLP storage factory working. andrew
Re: Security in Derby
On 2/21/07, Kim Haase [EMAIL PROTECTED] wrote: It seems that you can configure the network server in three different ways? 1) Setting the derby.drda.securityMechanism property on the command line, in the derby.properties file, or in the .bat or .ksh file, as documented in http://db.apache.org/derby/docs/dev/adminguide/adminguide-single.html#tadminconfigsettingnetwrokserverproperties Note that this is to be set on the server side only, and restricts the server to accepting connections from clients only with the specified security mechanism. Also, it might be nice to have a reference to these server properties in the tuning guide where all the other properties are mentioned so that there's a complete listing of the properties in one place. 2) In a JDBC program, calling the org.apache.derby.jdbc.ClientDataSource.setSecurityMechanism method 3) Specifying the connection URL property securityMechanism Note that these two are for specifying the security mechanism for the connection client side. But with the last one it seems you have to use a numeric literal? This seems unfortunate. I wonder if that is why it is not documented? I'm not clear on the reason for the lack of documentation, but I agree it is unfortunate. I've opened DERBY-2361 for adding documentation for the connection URLs. See also DERBY-963 for changing the client to use text names instead of numbers to match (1) and (2). andrew
Re: Security in Derby
On 2/20/07, Alexander Trauzzi [EMAIL PROTECTED] wrote: Awesome, I'm glad I can collect all these hidden links, but the issue of per user authentication, similar to what MySQL and other databases offer is still blocking me. Perhaps the issue here is that the information you are looking for is not in the Server and Administration guide, but in the Developer's guide? Have you read through the Derby and Security section here: http://db.apache.org/derby/docs/10.2/devguide/ Specifically, to use Derby's built-in user authentication and create the users and passwords for a database: http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure42374.html http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure21547.html http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure864642.html e.g., to create a user 'andrew' with password of 'newderbyuser' you can call, in ij: CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY( 'derby.user.andrew', 'newderbyuser') Then to enable the builtin authentication, you need to start the database with the following properties set: derby.connection.requireAuthentication=true derby.authentication.provider=BUILTIN You can set these properties at the database level by calling the set database property procedure, e.g. in ij: CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY ( 'derby.connection.requireAuthentication', 'true' ); and then shutting down the database engine and reconnecting to the database, as the derby.connection.requireAuthentication property is a static property. For a discussion of static vs. dynamic properties, see the Tuning guide, specifically: http://db.apache.org/derby/docs/10.2/tuning/ctunsetprop44147.html http://db.apache.org/derby/docs/10.2/tuning/rtunproper27467.html If you are connecting to the database over a network, you should consider using a non-cleartext password security mechanism, discussed in the server and admin guide here: http://db.apache.org/derby/docs/10.2/adminguide/cadminapps49914.html Anyway now that all the necessary properties are set, you need to connect to the database with the user and password you set, since authentication is enabled, by adding the appropriate user and password attributes to the JDBC URL, e.g. in ij: connect 'jdbc:derby:myDB;user=andrew;password=newderbyuser'; Note that this puts the user by default into the schema of their own username. e.g. if you create a table foo after you log in, it will be in the ANDREW schema, i.e. ANDREW.FOO. You can find further details for setting up user authentication in the PDF that was linked earlier, and in the manuals, but those are the basics. Did that help? cheers, andrew
Re: Security in Derby
On 2/20/07, Alexander Trauzzi [EMAIL PROTECTED] wrote: This is all very helpful. I will make a few notes however that you can take away from this... The method to implement encrypted passwords is far too complicated and involved for someone like myself who just wants to set up a secure server. This is mainly because nothing is said about what has to be done client side to ensure that the password being transmitted is what the server will end up wanting. Does the derby client network driver automatically encrypt passwords once the property is placed in the connection string? Unfortunately, the documentation mentions the DataSource values, but not the connection attributes. To connect using the strong substitute password, add securityMechanism=8 to the connection URL, e.g.: connect 'jdbc:derby:myDB;user=andrew;pass=newderbyuser;securityMechanism=8'; That's all you need to do. The connection will use the strong password substitute security mechanism. Encrypted username/password is security mechanism 9, but note that it currently only works with IBM JVMs. The docs could use some definite improvement here, and there is a JIRA entry entered for using user-friendly string values for the connection URLs instead of numbers: https://issues.apache.org/jira/browse/DERBY-963 It seems like there is a glut of property settings being used here on both client and server side and my wires are getting crossed trying to keep them straight. Ultimately this is impacting how easy it is to configure a derby server. Perhaps is there an index of connection string and server properties somewhere? How do I distinguish when a setting is for a database, or the system? There is an index of the various properties in the Tuning guide, see the section Derby Properties: http://db.apache.org/derby/docs/10.2/tuning/rtunproper32213.html There is discussion of static vs. dynamic and database vs. system scope there. There is a list of connection attributes in the Reference manual: http://db.apache.org/derby/docs/10.2/ref/rrefattrib24612.html Do properties that I set via a configuration file get retained between loads - as in, is it a needed only once thing? Can I delete the file and still have it's settings taking effect on a database between loads? No. For property settings to be retained in absence of a property file, you need to set them at the database level using the SYSCS_SET_DATABASE_PROPERTY procedures mentioned earlier so that the setting is stored in the database. Entire DB instance? Properties set that way affect a single database, but not the entire system. To set system properties, your application should call java.lang.System.setProperty(). Hope that helps, andrew
Re: auto truncation of varchar
On 2/20/07, Amir Michail [EMAIL PROTECTED] wrote:
Hi,
Is there a way to get derby to silently truncate varchar columns?
Could you use the substr function to accomplish this?
e.g.:
simple example:
create table foo (v varchar(5));
insert into foo values (substr('too long', 1, 5));
also works with prepared statements, here's an example from inside ij:
prepare ins1 as 'insert into foo values (substr(?, 1, 5))';
execute ins1 using 'values (''another'')';
ij select * from foo;
V
-
too l
anoth
hope that helps,
andrew
Re: Can't run the Eclipse plug-in labs
On 2/15/07, A. Rick Anderson [EMAIL PROTECTED] wrote: Bryan Pendleton wrote: 'jdbc:derby:net://localhost:1527/jayDB;create=true;user=APP;password=APP;'; Try taking the net: out. Having net: in there means to use the IBM DB2 JDBC driver, also called the JCC driver. The Derby JDBC driver just uses the prefix jdbc:derby:, so just say jdbc:derby://... Yeah, I saw this comment when I was googling. However, it is not clear to me where and how would I take out the 'net' from the URL? I, personally, am not creating, nor invoking, the connection URL directly. I am calling ij from Eclipse via the plug-in. I have not been able to locate where the URL is being defined in the ij.bat or the derby_common.bat files that presumably the Eclipse plug-in is calling. The only files where I can find that this string is found is in the administration manuals. What I am trying to do is follow the lab that comes with the Eclipse plugin. After installing, you are supposed to invoke 'ij' on jay_tables.sql script using the menu option Apache Derby-Run SQL script using 'ij'. This is where I get the error message. What lab did you get this script from? Have you tried following the instructions on the Derby website? http://db.apache.org/derby/integrate/plugin_help/start_toc.html The connect statement is an ij command in the jay_tables.sql script. You would need to edit that script to take the 'net:' out of the connection URL. HTH, andrew
Re: Fixed: Wrong ULR in Eclipse Plug-in Lab
On 2/15/07, A. Rick Anderson [EMAIL PROTECTED] wrote: That fixed it. A grep/search on the Java tree didn't show this connection URL anywhere and it never occurred to me that the URL would be embedded in the SQL script itself. I appreciate your help. Should I submit this to Jira as a bug, or did you already do that? Funny, I had never noticed that presentation and lab on the website before. I've fixed the URL in the lab, the update should be visible on the Derby website in about an hour, no need to file a bug. Thanks for noticing that and letting us know! cheers, andrew
Re: Error on using Ant to build Derby, Ant can not find compiler
On 2/4/07, Liese liu [EMAIL PROTECTED] wrote:
Hej everybody,
I am a newer of Derby. I download the db-derby-10.2.2.0-src.zip, when i use
Ant 1.6.5 build it, it alwasy occures the same error, i.e. Compiler Adapter
can't be found.
My OS is Win XP, following is my ant.properties and the build output.
j14lib= F:/j2sdk1.4.2_13/jre/lib
j13lib= F:/jdk1.3.1_19/jre/lib
build.compiler= F:\\j2sdk1.4.2_13\\bin\\javac.exe
proceed=false
sane=false
BUILD FAILED
F:\Derby\build.xml:347: The following error occurred while executing this
line:
F:\Derby\java\shared\build.xml:67: Compiler Adapter
'F:\j2sdk1.4.2_13\bin\javac.
exe' can't be found.
Total time: 1 second
Waiting for any reply!
Do not set build.compiler to the location of javac in your
ant.properties. Valid values for build.compiler are discussed in the
sixth paragraph under Description in the documentation for Ant's javac
task, here:
http://ant.apache.org/manual/CoreTasks/javac.html
Typically build.compiler should be set to 'modern', and Derby's
properties files for Ant set this value themselves.
e.g. in the top-level build.xml is this property file definitions:
property file=${properties.dir}/defaultcompiler.properties/
tools/ant/properties/defaultcompiler.properties sets:
build.compiler=modern
The javac that will be used will be the javac from the JDK with which
you are running Ant, i.e. from the jdk that is in your path, and Ant
will find it automatically.
HTH,
andrew
Re: Exception (nospc:nospc.U) thrown during batch updates
On 1/31/07, Hannes Grund [EMAIL PROTECTED] wrote: I'm using Derby 10.2.1.6,Java 1.6 on some linux box, during the execution of some batched prepared stamtenents, the following exception was thrown: 2007-01-31 11:35:08.310 GMT Thread[Thread] (XID =27813), (SESSIONID = 12), (DATABASE = /tmp/acc/2/DIR/var/home2/dir/db), (DRDAID = null), Failed Statement is: UPDATE Table SET a=?, b=?, c=?, d=?, e=?, f=? WHERE g=? ERROR nospc: nospc.U :at org.apache.derby.impl.store.raw.data.StoredPage.logRow(Unknown Source) at org.apache.derby.impl.store.raw.data.UpdateOperation.writeOptionalDataToBuffer(Unknown Source) Hi Hannes, At the very least you've discovered an exception that doesn't return a SQLState and without any text to explain the exception. In this case, I'm thinking it should probably be XSDA3: Limitation: Record cannot be updated or inserted due to lack of space on the page. Use the parameters derby.storage.pageSize and/or derby.storage.pageReservedSpace to work around this limitation. I'll file a bug for the exception's lack of content. Is this error consistently reproducible? If so, can you provide at the minimum the stack trace with the line numbers, and if possible, the complete list of columns in the table that was being updated along with their types and note which columns were being updated, and whether or not you were using the default values for page size and reserved space. If you can post a code snippet that reproduces the problem, that would be ideal. Thanks for the report, andrew
Re: Exception (nospc:nospc.U) thrown during batch updates
On 2/1/07, Andrew McIntyre [EMAIL PROTECTED] wrote: If so, can you provide at the minimum the stack trace with the line numbers Forgot to mention that line numbers for the exception can be provided if the error can be reproduced with the lib-debug distribution available from the download page: http://db.apache.org/derby/derby_downloads.html andrew
Re: renaming columns
On 12/29/06, Ralf Wiebicke [EMAIL PROTECTED] wrote: I'm wondering, that such a fundamental feature is not yet available in the latest release. I noticed derby, because its included in Java 6. So I thought, it's mature enough to support it in my project. All other databases I use do support renaming columns. I'm not yet sure, whether I want to work around this problem, or wait for the next release. Before the decision to open source Cloudscape as Derby had been made, an effort was already underway to make its SQL syntax more compatible with DB2 UDB. The DB2 UDB version which was current at the time, v8, did not support renaming or dropping columns. After Derby was open sourced, rename and drop of columns quickly became one of the most voted for items in JIRA, probably because most other database systems support it. A volunteer chipped in and now both rename and drop have been reimplemented in the trunk (thanks, Bryan!) and will be available in the next feature release. There are several workarounds which have been posted in previous threads. As an interesting side note, DB2 UDB v9 now has drop column support, but still no rename column. :-) cheers, andrew
Re: Re: Frustration: lack of alter table functionality
On 12/8/06, David Van Couvering [EMAIL PROTECTED] wrote: My understanding is that improvements are planned for the next release, 10.3. Altering a column to change its null / not null constraint [1], as well as the default value for a column [2], made it into the recent 10.2.1.6 release. Alter table drop column has been checked into the trunk [3], although there remains an issue when using alter table drop column with SQL authorization [4] that remains unresolved. It was decided that there was an acceptable solution for changing the data type for a column with the combined above functionality, see the discussion in DERBY-1515 [5]. [1] http://issues.apache.org/jira/browse/DERBY-119 [2] http://issues.apache.org/jira/browse/DERBY-1491 [3] http://issues.apache.org/jira/browse/DERBY-1489 [4] http://issues.apache.org/jira/browse/DERBY-1909 [5] http://issues.apache.org/jira/browse/DERBY-1515 I'm not sure where we stand on the date for that release - anyone have any info on the expected release date? At the moment, I don't think there are any concrete plans for a new feature release. Anyone interested in contributing to new features or release planning should subscribe to the Derby development mailing list and join the discussions there. andrew
Re: SQL for inserting BLOB data?
On 11/28/06, Ray Kiddy [EMAIL PROTECTED] wrote: If one is writing SQL to create tables and insert data and one has a BLOB column, how can one do this? There is not currently a way to do this with just SQL. However, there is an open JIRA for similar functionality and there has been some discussion around it. See: http://issues.apache.org/jira/browse/DERBY-378 http://mail-archives.apache.org/mod_mbox/db-derby-dev/200610.mbox/[EMAIL PROTECTED] Note that from the discussion, the functionality that would be provided would be a procedure to load the contents of a BLOB from a file. andrew
Re: Syntax diagrams - what format does Derby documentation use?
On 10/20/06, Laura Stewart [EMAIL PROTECTED] wrote: Can someone tell me what format Derby uses for the syntax diagrams? I need to understand what all the symbols mean - the vertical lines, the square brackets, the curly brackets, etc. Is there some standard format? Some web site that you can point me to that explains the syntax? Don't ask me why it's in the Getting Started guide, where there aren't actually any syntax diagrams, but there it is: http://db.apache.org/derby/docs/dev/getstart/rgsdocs10012.html That should probably move elsewhere, to ref and maybe also a copy in tools. andrew
Re: Problems connection to a secured DB via Client/Server-Driver
On 10/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I did the following steps: 1. Open a commandline window and starting the Networkserver D:\db-derby-10.2\binstartNetworkServer.bat Server is ready to accept connections on port 1527. 2. Open a second commandline window and starting ij 3. Connecting to the db H:\ij IJ Version 10.2 ij connect 'jdbc:derby://localhost:1527/e:/derbydbs/tests/testdb;user=admin;password=password'; FEHLER 08004: Connection authentication failure occurred. Reason: userid or password invalid. Just a guess without consulting the docs, but I think that the client doesn't consider 'e:' to be a valid part of the database URL. Try: in D:\db-derby-10.2\bin: set DERBY_OPTS=-Dderby.system.home=e:\derbydbs\tests startNetworkServer.bat and then in ij: connect 'jdbc:derby://localhost:1527/testdb;user=admin;password=password'; HTH, andrew
Re: Problems connection to a secured DB via Client/Server-Driver
On 10/13/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I want to connect via c/s-driver to a DerbyDB (Version 10.2.1.7), which is secured through user authentication properties in the service.properties file. The properties are: Are you putting these properties into the service.properties in the database directory? Because they should go into the derby.properties file in the directory defined in derby.system.home, and not into service.properties. service.properties should not be edited. For information on how to set properties, see: http://db.apache.org/derby/docs/dev/tuning/ctunsetprop32443.html http://db.apache.org/derby/docs/dev/tuning/ctunsetprop24222.html HTH, andrew
Re: Broken Links
On 9/26/06, Nowak, David J [EMAIL PROTECTED] wrote: Just about all of your hyperlinks on the http://db.apache.org/derby page are broken. The only link that I found working was the http://mail-archives.apache.org/mod_mbox/db-derby-user/200607.mbox/[EMAIL PROTECTED] download link. Are there specific links that were not working for you? I think there may have been some transient problems with the web server earlier, but I just went and clicked around on the front page and couldn't find any broken links. Where can I get more information about Derby and it's capabilities? The quick start page has some good pointers for getting started: http://db.apache.org/derby/quick_start.html And the manuals are a complete reference to Derby's capabilities: http://db.apache.org/derby/manuals/index.html There's also plenty of good information on the Derby wiki: http://wiki.apache.org/db-derby/ Please let me know if you continue to find broken links on the website. Thanks, andrew
Re: FW: Dbase Manager
On 9/22/06, Marl Atkins [EMAIL PROTECTED] wrote: Well I figured out a work-around. I just installed the whole Squirrel app into the directory hosting the database. Now if I could figure out how to make simultaneous connections I wouldn't have to keep opening and closing it. Any ideas? Again, this is an embedded database. Only one JVM is allowed access a Derby database at a time. In order to make multiple connections, you should have the embedded application start the network server when it starts up. This is referred to as an embedded server environment. Access from other JVMs can then be made using the client driver. See: http://db.apache.org/derby/docs/dev/adminguide/radminembeddedserverex.html So, for example, if you want to access the database with Squirrel while your applet is running with the database in embedded mode, then you should have the applet start the network server. You can then connect with Squirrel using the client driver. The url will be the same as the embedded URL, but with the addition of the hostname. e.g. 'jdbc:derby:mydb' in embedded becomes 'jdbc:derby://localhost/mydb' in the client driver. See the Server and Admin guide and the Developer's guide for more information on the network server and client. HTH, andrew
Re: Unsubscribe from mailing list
On 9/20/06, Max Ten [EMAIL PROTECTED] wrote: I had tried to unsubscribe by send a blank email to mailing address but didn't work. Wish to know is there any option i can unsubscribe? Thank you. To unsubscribe from derby-user, send a blank email to [EMAIL PROTECTED] If you are subscribed to the digest, send a blank email to [EMAIL PROTECTED] Then, follow the instructions in the confirmation mail that will be sent. Make sure that you send the mail from the address with which you are subscribed to the lists. Let me know if that doesn't work for some reason. cheers, andrew
Re: 10.2 licensing issue
On 9/11/06, Rick Hillegas [EMAIL PROTECTED] wrote: I can see two alternatives for us: 1. Ship 10.2 on the current schedule but do not include the JDBC4 drivers. When run on Java SE 6, Derby 10.2 would continue to expose our JDBC3 implementation. In addition, we would remove JDBC4-specific documentation from our user guides and prune out the JDBC4-specific javadoc. 2. Delay the current 10.2 schedule until after JDK 6 goes GA. At that time we could release a version of Derby which includes JDBC4 drivers. Given the length of time since 10.1 was released, the uncertainty of the exact date of JDK 6 shipment, and the number of new features included in +1 to option one, then. Should we plan to have another release with JDBC 4 once JDK 1.6 ships? andrew
Re: In Memory
On 7/31/06, Chris Forbis [EMAIL PROTECTED] wrote: I was looking at derby and the FAQ says in Memory version has not been completed, but to check with list.. It also said this about six months ago :) Just wondering if anything is being done on it... This feature request is being tracked with DERBY-646 in JIRA: http://issues.apache.org/jira/browse/DERBY-646 Feel free to pick up the work that has been done there and continue it if you are interested. There are comments in JIRA that describe what work remains to be done. If you are not interested in working on the feature, and the durability of your databases is not concern for you, then you could achieve similar performance by running with the property derby.system.durability set to test: http://db.apache.org/derby/docs/dev/tuning/rtunproperdurability.html HTH, andrew
Re: How To Run Derby on a PocketPC?
On 8/7/06, Marc Schlegel [EMAIL PROTECTED] wrote: Hi. I've posted a mail some weeks ago and received some help but I'm still not able to run Derby on a PocketPC. So I thought that I should start from scratsch. I'm working with WebSphere Device Developer 5.7 (wctme 5.7) and IBMs J9 VM. With my former attempts I wasn't able to get rid of an UnsupportedClassVersionError. I've read some posts that some people were able to tun Derby on PocketPc but those posts didn't tell me how. Could anybody tell me which steps are necesarry? Hi Marc, Have you tried running your application on wctme 5.7 using the jar files from the official release? http://db.apache.org/derby/releases/release-10.1.3.1.cgi If you are getting a stack trace or error while running with one of these jars, please post the full stack trace, and please also try to reproduce it using the lib-debug distribution so that it contains line numbers. If you are trying to build Derby from scratch, then you will need to follow the instructions in BUILDING.txt to the letter, but please note that it is not necessary to build Derby from scratch to get support for J2ME environments. That support is built into the jar files available in the official release archives available from the link above. HTH, andrew
Re: Re: Rename table error
On 7/21/06, Edson Carlos Ericksson Richter [EMAIL PROTECTED] wrote: I'm doing something wrong? Or it's known behavior? If yes, it's fixed in early releases? From the doc for RENAME TABLE: If there is a view or foreign key that references the table, attempts to rename it will generate an error. In addition, if there are any check constraints or triggers on the table, attempts to rename it will also generate an error. http://db.apache.org/derby/docs/dev/ref/rrefsqljrenametablestatement.html This is the behavior in the current release and in the trunk. andrew
Re: 'SYSCS_UTIL.SYSCS_EXPORT_QUERY' is not recognized as a function or procedure.
On 7/18/06, Sharath [EMAIL PROTECTED] wrote:
Hi all,
I wanted to export query reslut to a CSV file.
When i run 'SYSCS_UTIL.SYSCS_EXPORT_QUERY' with all
parameters it working fine from ij.
But when i run this from java it trhowing me the exception.
/snip
private class MyStoredProcedure extends StoredProcedure {
MyStoredProcedure(DataSource ds) {
logger.info(eventLogQuery constructor);
setDataSource(ds);
setFunction(true);
setSql(SYSCS_UTIL.SYSCS_EXPORT_QUERY);
logger.info(eventLogQuery setSql(SQL));
declareParameter(new SqlParameter(query, Types.VARCHAR));
declareParameter(new SqlParameter(path, Types.VARCHAR));
// You'll have to use the right types here
declareParameter(new SqlParameter(notUsed1, Types.CHAR));
declareParameter(new SqlParameter(notUsed2, Types.CHAR));
declareParameter(new SqlParameter(notUsed3, Types.VARCHAR));
compile();
logger.info (eventLogQuery compile());
}
/snip
Aby idea..?
Without seeing your StoredProcedure class or knowing the exception
that was thrown, my suggestion would be to make sure the SQL contains
the CALL keyword as well as the parameter markers. So in this case the
SQL should be: CALL SYSCS_UTIL.SYSCS_EXPORT_QUERY VALUES (?, ?, ?, ?,
?)
There are some JDBC examples of calling the Derby stored procedures in
some of the other descriptions of the stored procedures. If you could
post your StoredProcedure class and/or the exception that you get when
trying to run your example, I might be able to provide more insight
into why it is failing.
thanks,
andrew
Re: Apache Derby with Hibernate3 (more specificly GRAILS)
On 7/10/06, Lance Shaw [EMAIL PROTECTED] wrote: Hello, I'm tring to use Derby with GRAILS which uses Hibernate3. When I try to start the application using 'grails run-app' I get the following error: org.codehaus.groovy.grails.orm.hibernate.exceptions.CouldNotDetermineHibernateDialectException: Could not determine Hibernate dialect for database name [Apache Derby]!] Anyone know if there are dialect classes available for Derby to work with Hibernate3? Hi Lance, There is a Hibernate dialect class attached to this Hibernate JIRA issue: http://opensource.atlassian.com/projects/hibernate/browse/HB-1224 From the comments there, it appears that the class should be in Hibernate 3.0. There is also a GRAILS JIRA issue that seems to correspond to the error you are receiving: http://jira.codehaus.org/browse/GRAILS-129 which, from the comments there, appears to have been fixed for Grail .02 on May 31, 2006. So, if you are using GRAILS .01, this is probably the issue you are hitting. You may want to check with the GRAILS project to see if this is in fact the issue you are encountering. cheers, andrew
Re: Re: Derby plug-in for 10.1.3.1 - suggestion / contribution
On 7/7/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I believe the most important part about this checklist is to complete an ICLA. Also, please file a JIRA to attach the patch to. 3) Have you filed a JIRA before? I believe you need to get developer access to do so. If you don't have this access, post a message to the derby-dev mailing list to request this access. Hi Ian, You can file an issue without needing additional permissions. But to edit issues after they are filed, you will need to be added to the derby-developers group. You have two userids in JIRA, ianleslie and lesliesoftware, if you do need developer access to edit a JIRA issue, please let me know which id you would like granted access. Also, if you would prefer that I remove one of the accounts, I can take care of that as well. thanks, andrew
Re: Re: Trouble accessing read only DB with 10.1 (created and accessed fine with 10.0)
On 7/5/06, Andrew McIntyre [EMAIL PROTECTED] wrote: On 7/5/06, Leslie Software [EMAIL PROTECTED] wrote: I was using 10.0.2.1 and just this evening upgraded to 10.1.3.0 but I cannot open my read-only database any more. My connection code does this // Initialize the derby driver Class.forName (org.apache.derby.jdbc.EmbeddedDriver); //$NON-NLS-1$ // code that setups up connectionString eliminated myConnection = DriverManager.getConnection (connectionString); Where connectionString is: jdbc:derby:jar:(P:\WizardsFamiliar2\com.lesliesoftware.wizardsfamiliar.database\Cards.jar)MtGCards And there is a Cards.jar with a MtGCards database inside at the specified location. The call to getConnection throws the following execption: XJ040.C SQL Exception: Failed to start database 'jar:(P:\WizardsFamiliar2\com.lesliesoftware.wizardsfamiliar.database\Cards.jar)MtGCards', see the next exception for details. The next exception is: 40XD1 SQL Exception: Container was opened in read-only mode. I reviewed the 10.1 documentation and it looks just the same as in 10.0 http://db.apache.org/derby/docs/10.1/devguide/cdevdeploy11201.html. What am I doing wrong? What changes do I need to make? Ok, so I think I overreacted. The Derby documentation states this, in http://db.apache.org/derby/docs/10.1/devguide/cdevdeploy11201.html: Databases in a jar or zip file are always opened read-only and there is currently no support to allow updates of any type. This would include upgrade from a previous version of Derby. Someone else may correct me, but on reflection, I think this is in fact expected behavior. The JIRA issue I opened for this, DERBY-1479, I will leave open in order to improve the documentation to include the error you reported. andrew
[ANNOUNCE] Apache Derby 10.1.3.1 released
The Apache Derby project is pleased to announce the release of Derby 10.1.3.1, a maintenance release of Derby 10.1. Apache Derby is a subproject of the Apache DB project. Derby is a pure Java, standards-based relational database engine. Derby aims to be an easy to use solution for data management for software developers with zero administration for end users. Derby 10.1.3.1 can be downloaded at: http://db.apache.org/derby/releases/release-10.1.3.1.cgi What's new in 10.1.3.1: * Critical fixes for network client when used with a transaction manager (XA) * A critical data integrity fix when running with IBM J2RE 1.5.0 SR2. * fixes for network client when used with a transaction manager (XA) * Improved Network Server stability and reliability * Improved memory usage for the Network Client * Improved query performance for UNION queries and subqueries * Better handling of text encoding on systems with non-ASCII native encoding * More reliable behavior of scrollable insensitive result sets * Updated documentation * A new distribution that includes line number information, lib-debug, has been added to assist in filing and tracking down Derby issues * Many important fixes to correct issues with data integrity, correct memory leaks and address other product defects A complete list of fixes is available on the download page.
Re: building Derby on Mac OS X
On 7/2/06, Ray Kiddy [EMAIL PROTECTED] wrote:
I tried to build derby on Mac OS X and I had issues that I had not
expected.
I just wanted to report these for now and see it anyone has
suggestions on how to proceed. I am on a 10.4.7 system. The default
at this point is usually 1.5, but I set the default JVM back to 1.4.2
for the purposes of building derby.
It is necessary do this to build Derby 10.1 on any platform. See the
previous thread today concerning that. I thought that is was mentioned
in the build instructions (BUILDING.txt), but maybe not.
1) /snip description of modifying the source/target attributes
This should not be necessary. Could you post the errors you received
trying to build an unmodified source tree?
2) There were methods missing from some of the java.sql classes. A
couple of the interfaces were not completely implemented. I put in
stubs so that derby will compile. I would not expect them to work,
though.
This should not be the case. Could you also post these errors?
3) The code, as I checked it out, could not seem to find the
JVMInfo.J2SE_16 ivar. I see where this is defined, but I do not see
where the build system includes that class in the classpath of the
other build.xml files. I just changed the references to
JVMInfo.J2SE_16 to its value, 7.
I see the change that you made was to a file in the client code. When
the client code is built, the JVMInfo class, part of the engine,
should already have been built and be present in the output directory.
The compiler should pick it up from the output directory and not the
classpath.
Obviously, these are not the solutions to the issues. Are there other
solutions already in progress? Has anyone else build Derby on a Tiger
Mac OS X system? I will include my diffs below. I will also put the
contents of my ~/ant.properties file here.
I build on Mac OS X all the time without needing any source
modifications, as it's my primary development platform.
In case it helps, here's my ant.properties:
...
j13lib=/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Classes
j14lib=/System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Classes
java13compile.classpath=${j13lib}/classes.jar;${j13lib}/ui.jar;${j13lib}/i18n.jar;${j13lib}/sunrsasign.jar;${javatools.dir}/jdbc2_0-stdext.jar;${j14lib}/dt.jar
java14compile.classpath=${j14lib}/classes.jar;${j14lib}/ui.jar;${j14lib}/laf.jar;${j14lib}/sunrsasign.jar;${j14lib}/jsse.jar;${j14lib}/jce.jar;${j14lib}/charsets.jar;${j14lib}/dt.jar
deprecation=off
compile.classpath=${java13compile.classpath}
javatools.dir=${basedir}/tools/java
javadoc.tool.jdk14=${java.home}/bin/javadoc
...
The main difference seems to be the setting of the compile.classpath
variable. Try setting it equal to java13compile.classpath and let me
know if that helps.
cheers,
andrew
Re: building Derby on Mac OS X
So, I think that setting compile.classpath=${java14compile.classpath}
is definitely the problem here, since I just tried that on my machine
and the build breaks in similar ways to what you described.
On 7/2/06, Ray Kiddy [EMAIL PROTECTED] wrote:
The 1.3 JVM that is on the system
is deprecated. Really, it cannot be relied on for anything modern.
What the build is looking for is not the 1.3 JVM, but its class
libraries. Derby currently maintains compatibility with JDK 1.3.1
(JDBC 2.0), and so it needs to reference the class libraries to
compile the classes necessary to run Derby on JDK 1.3.1. But, you
should run Ant with a 1.4.2 JVM (for Derby 10.1 or earlier) or with
1.4.2, 1.5, or 1.6 (b86 or later) for Derby 10.2 / trunk in order to
build.
1) The build seems to assume that the default JVM is 1.3, but then it
does not actually build if one uses that setting.
The lowest JVM level that Derby supports is 1.3.1, but you need to run
Ant with a 1.4.2 or later JVM as mentioned above in order to build it.
Perhaps this should be made more explicit in BUILDING.txt.
compile.classpath=${java14compile.classpath}
should be set to the java13compile.classpath so that the class
libraries for JDK 1.3.1 are picked up for the compilations that
require them. From BUILDING.txt section 2.2:
(1) Derby build environment requires you to install two levels of
Java Development Kit (JDK) - 1.3.x and 1.4.x as Derby is designed
to work in JDK1.3.x (JDBC 2.0) and JDK 1.4.x (JDBC 3.0)
environments. The Derby build is set up such that that most of
the code is compiled against JDK 1.3.x libraries so that no
dependencies on JDK 1.4.x classes exist, except for the code
that only runs in JDK1.4.x. In addition Derby's JDBC 2.0
implementation must compile against JDBC 2.0 class definitions
and the JDBC 3.0 implementation against JDBC 3.0 class
definitions.
Conveniently, Mac OS X already has both 1.3.1 and 1.4.2 installed.
Note that there are some other libraries that need to be downloaded to
build a complete build, and these are mentioned in BUILDING.txt.
Note that when building to target a J2ME environment, that
compile.classpath should actually be set to reference the J2ME
classes, and not the JDK 1.3.1 classes. This isn't your concern, but
it's why there is a difference between compile.classpath and
java13compile.classpath.
So, try setting compile.classpath=${java13compile.classpath} in your
~/ant.properties and let me know if that solves your problem.
thanks,
andrew
Re: Using Derby within the JDK
On 6/29/06, Ray Kiddy [EMAIL PROTECTED] wrote: Does anyone still use korn shell? I know guys who used to work on mainframes who use it, but nobody else. Well, ksh is my preferred shell, but bash and ksh are so similar that I don't bother switching if I end up in one or the other. Take a look at DERBY-1032. I just uploaded a set of new scripts there that hopefully will go into the /bin directory of the distributions for 10.2. Just untar the file into where you put the rest of the -bin (or -lib) distribution. Setup will go something like: Set the DERBY_HOME environment variable to the location where you have installed Derby. Set JAVA_HOME to the home directory of a JDK or JRE installation. Then, add the /bin directory to your path like so: export PATH=$DERBY_HOME/bin:$PATH You should now be able to run the Derby tools. Confirm that the environment variables are set properly by running sysinfo: $ sysinfo ... show sysinfo output ... You can now use ij, the interactive JDBC scripting tool, to create a database and begin running SQL commands: $ ij ij Version 10.2 connect 'jdbc:derby:myDB;create=true'; create table t1 ( c1 int, c2 int ); etc. Also, 10.2 will have an executable jar file, derbyrun.jar, that provides easy access to the tools from the command line and are in the directory where you have installed Derby. e.g.: java -jar lib/derbyrun.jar ij will run ij. So, is anyone thinking of a more accessible set of docs on the initial setup? I am willing to write something, but I probably have a different approach to these things. The Working With Derby document aims to be a quick up-and-running guide for new users. It is also new with 10.2. See: http://db.apache.org/derby/docs/dev/workingwithderby/ cheers, andrew
Re: Status of adding BOOLEAN-type
Rick Hillegas wrote: Hi Kathey, Right now, I'm planning to back out BOOLEAN before the branch. Hi Rick, Don't you mean you'll back out the current BOOLEAN work from 10.2 *after* it has been branched? Or do you think we should give up completely due to the issues with the DRDA spec committee that you mentioned? andrew
Re: Proposal for 10.2 release schedule
OK, back to the 10.2 release schedule. How about this: early August - Feature work committed. 10.2 branch created. August/September - Proposed Final Draft of JDBC 4.0 goes public with updated evaluation license. Voting on a release candidate for 10.2 can begin as early as the day the PFD goes public September/October - GA of Derby 10.2.1, which includes whatever wording the spec requires regarding the JDBC 4.0 implementation in Derby. Release promoted to Apache mirrors. End of October - Expected GA of JDBC4 with Mustang, which includes a JavaDB version of Derby that is midstream between 10.2.1 and 10.2.2 November/December - Derby 10.2.2 follow-on release to remove the wording surrounding JDBC 4 bits that had previously been required by the spec license. Sound good? andrew
Re: generated by default question
On 6/16/06, Michael Segel [EMAIL PROTECTED] wrote: I think we'll just have to agree to disagree. Whether you agree or disagree doesn't change the fact that this is a bug. Whether or not this is a bug is not a 'fact'. That there is disagreement would imply that such a determination lies more in the realm of opinion. Here's a free clue. If I can't trust Derby to autogenerate a value by default that will insert a row which has no other problems or contraints, then I can't use Derby. Are you trolling for responses here? Sure seems like it. Hey folks: don't feed a troll. A database system should be expected to issue an error when a sequence generator hits an unusual condition. Unexpected data in a table with a primary key that is an identity column which is generated by default is but one of many such possibilities. cheers, andrew
Re: Derby hogging CPU on startup
On 6/9/06, Mueller, Stephen Ng [EMAIL PROTECTED] wrote: I am using emdedded Derby for one of my applications. After calling connection.open() on the database, the connection is returned promptly with no problem. What API is the connection.open() method from? It's not a JDBC method. However, after this, my CPU usage goes to nearly 100%, and my computer slows down. I can perform inserts on the database while this is happening, but they take a while. Is Derby going through some sort of start up procedure? Derby start up, even on an underpowered desktop by today's standards (where underpowered = 400 Mhz P3 or 450 Mhz G4) Derby startup shouldn't take more than 10 seconds, even when creating a new database. Should it be taking up this much CPU? It takes about a minute or so before completing, and my CPU usage returns to normal. No, I don't think this is normal, and I have not experienced this behavior before. When starting Derby, there is usually an initial spike, though not even to 100% in most cases, and then CPU usage quickly returns to normal. What platform and JVM are you using? Perhaps there is something odd going on with the JVM here. How much RAM do you have? Perhaps the machine is running out of physical memory and there is an excessive amount of access to virtual memory? Anyone know why this is happening and how/if I can alleviate the problem? FYI, I am using Derby 10.1.2.1. Nothing recent rings a bell. I've seen CPU spikes in the past, but not recent past - back in the JDK 1.1-era. Any additional details concerning your setup and how you are accessing Derby might be useful in tracking down the problem. Thanks, andrew
Re: 10.2.0.1 snapshot posted
On 5/26/06, Craig L Russell [EMAIL PROTECTED] wrote: Does this mean that the official release might actually be something like 10.2.0.8, considering the number of cycles that we might go through over the next several months? From http://db.apache.org/derby/papers/versionupgrade.html: Fixpack (f) of 0 (zero) is a special value that indicates alpha quality software and causes version string to be appended with the word 'alpha'. Additionally a boolean beta flag exists, which when true causes the version string to be appended with the word 'beta' to indicate beta quality software. So, the first real release candidate would have both the third digit bumped to 1, the fourth digit zeroed out, and the beta flag set to false. So the first release off of 10.2 will be (at least) 10.2.1.0. If there's a formal beta period and Rick decides to make the beta 10.2.1.0, then the first real release candidate might be 10.2.1.1. That's up to him. :-) andrew
Re: In-memory store implementation available for contribution (was: Re: derby-user Digest 20 May 2006 17:44:25 -0000 Issue 322)
On 5/22/06, David Van Couvering [EMAIL PROTECTED] wrote: Great! I'm not sure what you mean by a copy of the jar file but we'd of course like to see the source, not just the binaries. The student must explicitly indicate that he is handing over the code to the ASF. The normal way this is done is to create a JIRA item (our bug tracking system) and then put the changes he's made as an attachment to this JIRA item, indicating he is granting the code to the ASF. I'd be happy to help guide the student through this process. Better yet, we should have one of our store experts work with the student to look at getting his code in. Any volunteers? I believe we already have the source: http://issues.apache.org/jira/browse/DERBY-646 Attached as 'svn.diff'. There were some problems as far as getting this committed, though. Dan thought this crossed the threshold of requiring the contributor to submit a CLA (although the author did choose the 'grant license to ASF' option in JIRA), and there were other issues: lack of comments and lack of tests. I suspect the original author may not be interested or have time to finish the patch beyond what's already been contributed. Some other motivated person could pick up this contribution and take it the rest of the way, though. andrew
Re: Derby Protocols
On 5/20/06, Maryam Moazeni [EMAIL PROTECTED] wrote: What is the difference between this jdbc:derby://localhost:1527/ This form is used when connecting to the network server with the Derby network client driver, from derbyclient.jar. AND jdbc:derby:net://localhost:1527/ ?? This form is used to connect to the network server with the DB2 Universal JDBC driver, from db2jcc.jar best regards, andrew
10.1.2.4 snapshot posted
Hi derby-dev and derby-user, I have just posted a new snapshot for 10.1 as we are heading towards a 10.1.3.0 release: http://db.apache.org/derby/derby_downloads.html#Snapshot+Jars You may need to refresh the page in your browser to see the update. If you are interested, please download and test the snapshot. Links to the lists of the various issues that have been fixed are linked from the web page above. This time, I have also included a debug snapshot which contains jars whose classes have been compiled to include the line number tables for easier debugging (see DERBY-178). Areas of particular improvement include XA behavior (DERBY-966 and many others), query performance with subqueries containing UNION operators (DERBY-649, DERBY-805), client/server reliability (DERBY-125, DERBY-170, DERBY-777), inplace compress (DERBY-1187), and many more. Please report any further issues you find with the snapshot to JIRA: http://issues.apache.org/jira/browse/DERBY Thank you! andrew
Re: How Open Source Works (was Re: Spawning Data on Multiple Directories)
On 5/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Yet, when user's constantly ask for features that are not currently implemented in Derby, they are all pointed to creating a Jira entry. Yes, because that's the first step to working on something here, and the last for a user without the time to get involved. Even large, complex, architectural issues can be resolved by a single user if they are willing and able and have enough time and support. That's what Google's Summer of Code is all about, for example. The effort involved in implementing the originally requested feature is unknown, since all that's been done so far is to describe the feature. Personally, I don't think the effort involved with what Rodrigo requested is necessarily that large. It is only when someone points out that there needs to be a redesign of Derby to allow for a systematic approach or to discuss the ramifications of these requested mods that you step in and try to control the discussion. I have seen neither any evidence that this user's requested feature requires a redesign of Derby nor have I seen that anyone is trying to control discussion about the feature. In fact, I suggested that discussion about the feature continue on the dev list if Rodrigo was interested in working on it and that seems to be as far as it's gone. andrew
Re: How Open Source Works (was Re: Spawning Data on Multiple Directories)
On 5/5/06, Michael Segel [EMAIL PROTECTED] wrote: Posting in Jira and introducing it are two different things. Filter by Resolved. I notice that there is an Andrew McIntyre who works for IBM in Atlanta. Is that you? Nope. andrew
Re: Spawning Data on Multiple Directories
On 5/4/06, Rodrigo Madera [EMAIL PROTECTED] wrote: What I'm asking for is available in other DBMS, where you specify how many bytes to store in each directory. So you can make special combinations on this. Indeed there is a select group of people to actually take advantage of such a feature. I'd suggest filing an enhancement request in JIRA. As you point out, there may be others who would like such a feature and if their is a JIRA filed for it, those interested can track any progress. Of course, people who are playing with embedding databases in web pages will be concerned. In that case, turn the plugin off. People who upload the Derby engine in their wrist watch will like it to be small too... but then again, is Derby supposed to be functional? small? 100% Java?... Why not all of the above? Just make it modular. Derby is somewhat modularized but could probably use some improvement in this area. But there is a StorageFactory interface that might make it easier for you to write support for this feature. For example, one user wrote an all-in-memory StorageFactory: http://issues.apache.org/jira/browse/DERBY-646 Perhaps you could write a StorageFactory that allowed you to span multiple disks. I don't know if that's possible, since I'm not an expert in the store code, but at first glance it seems like it might. I would love to contribute on the spirit of open source and make such an improvement, but I just don't have time to Get To Know The Code (TM) first. If there was a structured and accepted plugin engine I would definitely invest two weekends on this. After filing the enhancement request in JIRA, I would suggest following up on derby-dev. You can probably get some pointers from people knowledgable in the relevant code who could help you scope out the project and help you determine if this is possible and something you have time for. Best regards, andrew
Re: derby exception
On 4/20/06, shashanka tilak [EMAIL PROTECTED] wrote: I get the following exception when I run the program. I did not jar the compiled classes. The classes are in exploded directory structure. A new directory derbyDB\log was created. And derby.log shows the following exception. I would really appreciate if someone can give explanation. Thank you. 2006-04-17 16:06:58.625 GMT Thread[main,5,main] Cleanup action starting java.lang.NullPointerException at org.apache.derby.impl.store.raw.log.LogToFile.getFirstLogNeeded(LogToFile.java:2103) At this point in the code, a log file is expected to be in the log directory, but from your comments the log file has not been created. Do you have the correct permissions to read/write to the directory? Is the disk full? From the exception you're getting, it would seem that uselessLogFile is null, thus the call to getPath() throws a NullPointerException. It's not quite clear to me how this could happen, but perhaps someone more familiar with the store code could answer that question. andrew
Re: DITA Advice?
On 11/16/05, Andrus Adamchik [EMAIL PROTECTED] wrote: So.. Can anyone recommend an inexpensive (or preferably open source) DITA content editor? Our experience shows that the need to edit XML by hand discourages participation. Just searching through Google found me this: http://www.techwr-l.com/techwhirl/archives/0507/techwhirl-0507-00396.html Also is there a way to integrate DITA with a Wiki-type system? I'd really love to take documentation out of the CVS and put it on Wiki. This would be ideal for collaborative docs writing. Like, say, a DITA-to-Confluence sort of plugin? That would be nice, wouldn't it? Google gave me this: http://jira.atlassian.com/browse/CONF-5926 Does anyone else on the list have any other pointers or suggestions? andrew
Re: Derby fails inserting a join
On 3/8/06, mark boylan [EMAIL PROTECTED] wrote: Hi Satheesh, Can you give me the link for JIRA? http://issues.apache.org/jira/browse/DERBY Further info about filing issues in JIRA is on the website, click the Community tab, then the BUGS list on the left. Or this link will take you straight there: http://db.apache.org/derby/DerbyBugGuidelines.html andrew
Re: Generating user docs
On 3/3/06, Rick Hillegas [EMAIL PROTECTED] wrote: For instance, when I try to build the postscript version of the Developer's guide (ant -quiet pdf.devguide), I get a directory (out/devguide) with a derbydev.fo file and several gifs. But no .pdf file. Would appreciate advice on what I am doing wrong. Hard to tell without an error, but clearly FOP is having some trouble. Are there any obvious errors from FOP in the non-quiet ant output? Try running with -verbose and make sure the call to FOP is actually happening. andrew
Re: How can I get sysinfo for a custom Derby classloader?
On 2/22/06, Kathey Marsden [EMAIL PROTECTED] wrote: 2) Will DERBY-668 mean that it won't print the right information anyway, even if I get the coding right? Unfortunately, I'm sure this is true. Sysinfo currently parses the contents of the classpath for jar files and then looks for the info properties files in them. As in DERBY-668, if the Derby classes are loaded by a classloader, then derby.jar won't be on the classpath and sysinfo will not report it's information. andrew
Re: [WWD] Feedback requested on Chapters 1 and 2 of Working With Derby
On 2/20/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: 2) Now start the command line processor c:\ ij Dan, expanding on your previous idea, what if we add a class to derbytools.jar as it's default run class that just switches on the available tools, then you can do: java -jar lib/derbytools.jar ij java -jar lib/derbytools.jar sysinfo java -jar lib/derbytools.jar dblook etc. I have a prototype for this that I'll post to derby-dev. andrew
Re: Incorporating the new derby logo into the web site
On Dec 21, 2005, at 7:57 PM, Jean T. Anderson wrote:We voted for more than just the one version of the logo with the text. In any event, that specific logo is great for the Derby documentation, but it's too wide for web site display. The screen shot at http://issues.apache.org/jira/secure/attachment/12321496/web-preview-20dec05-2.png doesn't show what it looks like when you expand/reduce the browser window. The image displayed on the web site needs to be more narrow. I realize this isn't the best solution, but couldn't we put the current logo in a fixed div as-is? And maybe swap the Derby and DB logos. Yes, that means one of them flows off screen while the rest of the website fits in the window width. But I wanted to point it out as another possible option. I just attached a version of the logo with the logo text at the current size, but rearranged to make it more narrow: http://issues.apache.org/jira/secure/attachment/12321510/derby-logo-move.jpgI can also resize and adjust this text however you like, and I think it keeps more to the spirit of Roger's original submission to retain the typeface and use of bold text. I could make this prettier by reducing the size somewhat and right aligning the text, but I thought I would run this first version by you to see if that was sufficient, and to get your feedback on using a fixed div for the logos on the page (with either logo.)andrew
Re: [VOTE] Apache Derby logo
On Dec 2, 2005, at 1:54 PM, David W. Van Couvering wrote: This is a vote for choosing a logo for Apache Derby. I vote for none of the above. Although a couple of the entries are very nice, I also would like to see more refinement of the ideas presented. andrew
[ANN] Apache Derby 10.1.2.1 released
The Apache Derby project is pleased to announce the release of Derby 10.1.2.1, a maintenance release of Derby 10.1.1.0. Apache Derby is a subproject of the Apache DB project. Derby is a pure Java, standards-based relational database engine. Derby aims to be an easy to use solution for data management for software developers with zero administration for end users. Derby 10.1.2.1 can be downloaded from: http://db.apache.org/derby/releases/release-10.1.2.1.cgi The changes in the Derby 10.1.2.1 release since the official 10.1.1.0 release include: - Globalization of the 10.1 error messages. - Eclipse 3.1 support. - Ability to run on all Mac OS X JVMs with no special configuration. - The JVM -jar option can start the network server from derbynet.jar. - Better support for loading databases from jars in the classpath. - Improved J2ME support. - Improved security manager support. - Fixes for many other issues. For a complete list of changes in the release, please review the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12310270styleName=TextprojectId=10594Create=Create
Re: Derby and portability
On 11/16/05, Rajesh Kartha [EMAIL PROTECTED] wrote: Not sure, but shouldn't the JIRA issue, DERBY-588, be considered when we claim the portability of a Derby database. Database created in zOS does not boot in Windows due to the encoding of the service.properties file. http://issues.apache.org/jira/browse/DERBY-588 Hmm... We use the java.util.Properties load and store methods to read/write the service.properties file. If the z/OS JVM is writing the service.properties out as EBCDIC (I assume) instead of Unicode Escape format as specified in the javadoc for Properties.store(), then it is a JVM bug, not a Derby bug. See: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Properties.html#store(java.io.OutputStream,%20java.lang.String) andrew
Re: [Fwd: Re: Are you happy with Derby?]
On Oct 27, 2005, at 8:17 PM, Michael J. Segel wrote:Apache is great if your goal is to take and use the IP or embed the product in your application for resale. It sucks if you're a developer and want to extend an existing app with some new IP that has some monetary value. This is what I meant about protecting your IP. I think you've got it a little backwards, I think. The GPL requires that any modifications to GPL-licensed code be distributed under the GPL as well. This allows resale, but not extension, without releasing the source to your modifications. Thus, if you combine your IP with GPL-licensed code, you have to release the source to your IP. If anything, this means that the original copyright holder has the right to use your IP in their GPL-licensed product as well, for free. This pushes your IP back up to the original copyright holder.The ASL does not require the distribution of source modifications combined with works licensed under the ASL. It is your choice to contribute them back to the original project. You can choose not to release the source to modified ASL code to the public - thus protecting your IP - without being in violation of the ASL.That's the kicker. The kicker is that this isn't the place for license discussions, it's a place to discuss using Derby. While licensing is a part of that, there are other places - and lawyers - for determining whether a particular software license is a good fit for your needs.Your input is appreciated, of course. And while I couldn't help but chime in, I think this discussion has meandered a little far off courseandrew
Re: Are you happy with Derby?
On 9/9/05, Michael J. Segel [EMAIL PROTECTED] wrote: The only drawback is that Derby is under GPL. So as long as you follow GPL's rules, you're ok. Being an Apache project, Derby is licensed under the ASL v2, not GPL. http://db.apache.org/derby/license.html http://www.apache.org/licenses/LICENSE-2.0.html andrew
Re: Still no bin directory in Derby?
On 8/8/05, Jonathan Eric Miller [EMAIL PROTECTED] wrote: I thought by the first official release of Derby there would be a bin directory with scripts for running the tools such as ij. For example, I thought there would be ij.cmd and a ij.sh. i.e. similar to what Tomcat does. This would be nice IMHO. Hi Jonathan, Scripts for setting the classpath and running the utilities are in the frameworks directory of the -bin distribution. There are two separate sets of scripts to use, depending on whether you want to use embedded or network server mode. There's no top-level bin directory because the scripts for each mode have similar names, and with separate directories its more clear which scripts you are using. Plus, presumably, if other methods of access are added, e.g. ODBC, or if someone wanted to contribute scripts that would make getting Derby up and running on different application servers running, e.g. Tomcat, then these could be added to new directories under frameworks. I'd like to encourage anyone with such scripts to post them to the list for others to use, as well. :-) cheers, andrew
Re: Dead link on Derby documentation page
On 8/4/05, vantine, lee [EMAIL PROTECTED] wrote: The link to the PDF version of the Derby Reference manual is dead. The links to the HTML formats are ok. Thanks for spotting that! I've updated the site to fix the link. The new page should become active within the next 2-4 hours. andrew
Re: Derby with OS X Tiger (10.4) Java 1.5.0_02? Log problem?
On Aug 4, 2005, at 3:28 PM, Barnet Wagman wrote: Has anyone successfully used Derby with OS X 10.4 and Java 1.5.0_02? I'm getting the Cannot log transaction changes ... problem (http://issues.apache.org/jira/browse/DERBY-1) even though I've used the derby.storage.fileSyncTransactionLog=true fix. I am able to create a database and put data into it. But after shutting down and starting a new session, I get the log transaction ... error when I try to add to it. Hi Barnet, When you shut down and start a new session, you need to set that system property in the new session as well. Because this is a general problem with the way the Apple JVM writes rws mode files, you need to force Derby to use rw mode each time you start up, or the same error will be hit when Derby attempts to write new data. As you have discovered, reading files works as expected, but the bug in the JVM is only hit if you attempt to write. Try setting that system property each time you connect and you should be able to write new data to the database in each session, so long as that system property is set each and every time before you obtain a connection to the database. The property can also be set in the derby.properties for that database. For more information on how to do that, please see the section Changing the system-wide properties by using the derby.properties file in the Derby Tuning Guide: http://db.apache.org/derby/docs/10.1/tuning/ about half way down the page. Note that the file needs to be in the location specified by the derby.system.home property, and that there is only one derby.properties per system, not per database. hope that helps, andrew
Re: Derby with OS X Tiger (10.4) Java 1.5.0_02? Log problem?
On Aug 4, 2005, at 8:56 PM, Barnet Wagman wrote: When you shut down and start a new session, you need to set that system property in the new session as well. Yes, I'm doing that. My code contains two getConnection() calls, one when it starts and the other as an explicit shutdown. The startup sequence is System.setProperty(derby.storage.fileSyncTransactionLog,true); new org.apache.derby.jdbc.EmbeddedDriver(); con = DriverManager.getConnection(...); I don't reset the system property again prior to the shutdown, e.g. DriverManager.getConnection(jdbc:derby:;shutdown=true); but I can't see how that would matter. I rigged up the SimpleApp demo program to do some inserts, shutdown the database and then reconnect using DriverManager.getConnection() calls and do some more inserts/updates. This works for me on 10.4/ Java 1.5.0_02. I'm sure this is far simpler than what you are trying to do, but maybe it will help you to pinpoint where things are going wrong. I've attached the modified SimpleApp below. Is there any other way to force Derby to use rw mode? I've read about a patch, but it wasn't clear how to implement it. With a little work, it should be possible to apply Suresh Thalamati's patch for this issue: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200410.mbox/% [EMAIL PROTECTED] to the latest code, but if I remember correctly, there were some concerns about how it might affect recovery, and it has not been extensively tested. hope that helps, andrew SimpleApp.java Description: Binary data
[ANNOUNCE] Apache Derby 10.1.1.0 Released
The Apache Derby development community is pleased to announce its first release after graduating from the Apache Incubator, Apache Derby 10.1.1.0. Apache Derby is now a subproject of the Apache DB project. You can find Derby at its new home on the web at: http://db.apache.org/derby/ Apache Derby 10.1.1.0 can be downloaded from the following page: http://db.apache.org/derby/releases/release-10.1.1.0.html Derby is a pure Java, standards-based relational database engine. Derby aims to be an easy to use solution for data management for software developers with zero administration for end users. This release includes a new open source network client driver, as well as a number of other new features and enhancements: * Support for J2ME/CDC/Foundation with JSR-169 JDBC subset * Online compress functionality for reclaiming disk space during operation * XA support for Network Server * Increased identifier lengths to 128 characters for all identifiers * Added SQL: INTERSECT and EXCEPT * Added SQL: SYNONYM * JDBC Updatable Result Sets * ORDER by expressions * Allow insertions into an identity column * Support for explicit Java method signature in function and procedure definitions See the CHANGES file in the distributions for a full list of other changes.
Re: Derby and MacOS X
On May 10, 2005, at 9:02 PM, Andrew Kachalo wrote: After adding derby.jar and derbytools.jar to project, I tried each of next two lines of code, but it returns No Class Def Found Exception : Class.forName(org.apache.derby.jdbc.EmbeddedDriver).newInstance(); DriverManager.registerDriver (new org.apache.derby.jdbc.EmbeddedDriver()); How to solve this problem? Make sure that you add the files to the lib directory of the Xcode project. Jar files added to the lib directory will automatically be added to the classpath for compilation and execution. To do this, right click or control-click the lib folder underneath the main project icon and select Add... -> Existing Files..., select derby.jar and then click Add. Click Add in the next dialog box and you should be ready to go. andrew
Updated snapshot jars
Hello all, This afternoon I updated the snapshot jars posted on the downloads page. It would be great for anyone interested in the Derby network client driver which was recently added to the trunk (10.1.0.0 alpha), or any other recently added feature or bugfix in which you are interested, to test them out and report your findings. Those interested in testing Derby on their favorite platform/JVM will find the corresponding derbyTesting.jar in the snapshot file. Also, please note that the zip snapshots were generated on Windows and the tar.gz snapshots were generated on Unix, so text files in the snapshots should have the proper line endings. Here are the highlights for each new snapshot: 10.1.0.0 alpha - FOR TESTING ONLY. Please see the warning about using alpha releases on the downloads page: http://incubator.apache.org/derby/derby_downloads.html#Development+trunk - Derby network client driver added. Use the included derbyclient.jar in place of db2jcc.jar. Additional information on its use can be found in the functional specification attached to this post: http://article.gmane.org/gmane.comp.apache.db.derby.devel/2960 - DATE and TIMESTAMP functions which correctly match the documentation - First phase of online compress functionality - Derby-176: queries with extensive joins no longer cause java linkage error - Derby-186: Set currentPosition for scrollable cursors when moving past the last row - Derby-134: Improvement to allow ordering by expressions, instead of correlation names or column positions only. - Derby-96: beginning support for recovery from out-of-order log records - Derby-106: spill BackingStoreHashTables to disk to prevent out of memory errors in hash joins - DERBY-158: PRIMARY KEY does not imply NOT NULL - INTERSECT/EXCEPT support - Preliminary JSR169 support - Snapshot includes demo and scripts - Fixed Eclipse plugin version specification - Lots more that I've left out :-) 10.0.2.2 - please note that this is not an official release - LOCAL is no longer a reserved keyword - Demos and scripts included in the snapshot - Fixed Eclipse plugin version specification A full list of fixed bugs in each version can be found here: http://issues.apache.org/jira/secure/BrowseProject.jspa? id=10594subset=-1 andrew
Re: Equivlent to MySQL DESCRIBE statement?
On Thu, 10 Feb 2005 15:52:43 -0600, Jonathan Eric Miller [EMAIL PROTECTED] wrote: I'm guessing that at some point there will be UNIX shell scripts/DOS command files for commands such as ij, dblook, and starting Derby as a network server? Jon Hi Jon, There are currently scripts checked into Subversion. You can view and download them here: http://svn.apache.org/viewcvs.cgi/incubator/derby/code/trunk/frameworks/ Scripts for Network Server are in the NetworkServer/bin directory and scripts for use in embedded mode are in the embedded/bin directory. I will work on putting them together a new snapshot of the jars so that they are downloadable from the Derby website. andrew
Re: Derby, CodeWarrior and MRJ
On Feb 3, 2005, at 12:29 AM, Andrew Kachalo wrote: I use MacOS 9.1 with MacOS Runtime for Java 2.2.3 and CodeWarrior 7.1 Any version of MRJ is equivalent to a JDK 1.1.8 JVM, which is not supported by any version of Derby. MRJ 2.2.3 is over 5 years old, and MacOS 9.1 is over four years old at this point. It is interesting to me that you would try to use Derby with this particular OS/JVM combination. Out of curiosity, is there a reason why you cannot currently use a newer version of Mac OS and its associated Java environment? andrew
Re: HTML documentation in a .zip or .tgz file?
On Oct 27, 2004, at 2:29 PM, J. David Eisenberg wrote: I'd love to have all of the HTML pages in one .zip or .tgz file, though, so I can read documentation without having to be online. There's no zip or tgz posted anywhere, but the manuals are what you see on the website. If you have svn, you can get a copy of the website with: svn co http://svn.apache.org/repos/asf/incubator/derby/site/trunk/build or you can use a utility such as wget to download the website to a local copy: wget -m -r -np http://incubator.apache.org/derby/ and always be careful with recursive web downloads. :) andrew
