db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrna van Lunteren <m.v.lunte...@gmail.com>
Subject Re: Confusing error message on boot?
Date Tue, 17 Nov 2009 17:41:54 GMT
On Tue, Nov 17, 2009 at 9:35 AM, Knut Anders Hatlen <Knut.Hatlen@sun.com> wrote:
> Kristian Waagan <Kristian.Waagan@Sun.COM> writes:
>> Hi,
>> Working on the drop database feature (DERBY-4428), I noticed this:
>> ij> connect 'jdbc:derby:memory:test;shutdown=true;drop=true';
>> ERROR XJ048: Conflicting boot attributes specified: shutdown, drop
>> ij> connect 'jdbc:derby:memory:test;shutdown=true;create=true';
>> ERROR XJ004: Database 'memory:test' not found.
>> The error XJ0048 is new (I'm considering adding it).
>> However, note that if you specify both shutdown and create you're told
>> that the database doesn't exist. What happens is that the shutdown
>> attribute takes precedence over the create attribute.
>> Should we change this to show something like XJ048?
> That sounds like a more reasonable response, at least.
>> Can we change it without causing trouble for existing applications?
> The potential incompatibility here, if I understand correctly, is that
> if the database 'test' is booted when that command is issued, the
> command currently shuts down the database, whereas with the suggested
> change it reports that the attributes are in conflict and leaves the
> database booted?
> The combination of shutdown=true and create=true doesn't make much sense
> (unless it meant create a database and shut it down cleanly, which it
> doesn't). So if we haven't documented anywhere that shutdown takes
> precedence over create, I wouldn't think it's very problematic to
> disallow the combination.
> --
> Knut Anders

I wrangled with this a bit when I was working on the
jdbcapi.*DSCreateShutdownDBTest.java tests. It appeared at the time it
was a given that if you use opposing details, you may get unexpected
results. I may have made a change in the docs to state that - I can't

I like the idea of XJ048 message better...+1

I don't think it likely, but it's still possible this may cause
trouble for existing applications, someone might be checking for
SQLState XJ004... (like in the test)? So not something suitable for a

>From looking at that test, I also think there may be an issue with
network server vs. embedded; network server apparently issues a 08004


View raw message