> I don't understand the complexity of the INSERT/UPDATE/DELETE piece. Why
> does the application need to issue INSERT/UPDATE/DELETE against the view
> rather than directly against the user-specific table?
Because nothing's ever easy :). Long story short, we're currently
developing an automatic in
Hi Matt,
Knut has just suggested a candidate solution involving table functions.
At first blush it seems to me that your problem has two pieces to it:
the SELECT piece and the INSERT/UPDATE/DELETE piece.
For the SELECT piece, it seems to me that your current solution will
work on Derby as we
Matt Kendall <[EMAIL PROTECTED]> writes:
> I need functionality in Derby that I don't think it currently
> provides, so I'm looking to extend Derby to provide it. As part of the
> product that I'm working on, I'll be automatically installing Derby
> databases in a standalone server mode. Each data
I need functionality in Derby that I don't think it currently
provides, so I'm looking to extend Derby to provide it. As part of the
product that I'm working on, I'll be automatically installing Derby
databases in a standalone server mode. Each database will contain one
schema with "shared" data, a
