Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Subject: Re: Importing tables which have references to other tables
From: Tim Watts <tim@cliftonfarm.org>
To: Derby Discussion <derby-user@db.apache.org>
In-Reply-To: <1339762688.30268.130.camel@dellberry>
References: <34016274.post@talk.nabble.com>
	 <1339762688.30268.130.camel@dellberry>
Content-Type: multipart/signed; micalg="pgp-sha1";
 protocol="application/pgp-signature"; boundary="=-PasPzxy3OL/GkSIsiDsf"
Organization: Clifton Farm
Date: Fri, 15 Jun 2012 08:24:01 -0400
Message-ID: <1339763041.30268.133.camel@dellberry>
Mime-Version: 1.0


--=-PasPzxy3OL/GkSIsiDsf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2012-06-15 at 08:18 -0400, Tim Watts wrote:
> On Thu, 2012-06-14 at 23:26 -0700, jaz1988 wrote:
> > Hi,
> >=20
> > I have a table, TABLE1 which has a column which is GENERATED BY DEFAULT=
 AS
> > IDENTITY. I managed to export this table and import into an existing DB=
 with
> > the same table. The import is able to adjust the IDENTITY column accord=
ingly
> > with regards to the existing data in the table.=20
> >=20
> > The problem is, I have another table, TABLE2 which has a foreign key th=
at
> > referenced to the IDENTITY column in TABLE1. When the IDENTITY column i=
n
> > TABLE1 is adjusted after import, the import of TABLE2 will fail since t=
he
> > References is messed up already. Am I doing it right or is there other =
ways
> > to do import and exports of Tables with references.
> >=20
> > Thank you!
>=20
> Since you specified BY DEFAULT that means you can import TABLE1 using
> the existing id values so that when you import TABLE2 you shouldn't have
> any referential integrity issues.  But, of course, you'll want to export
> the id values from TABLE1.
>=20
> I was able to do this using Derby's SYSCS_UTIL.SYSCS_IMPORT_DATA
> procedure.
>=20
Let me further point out that you should read the fine print for
generated-column-spec in the Derby SQL manual under Create Table /
column-definition / generated-column-spec, especially the part about
using a START WITH clause.


--=-PasPzxy3OL/GkSIsiDsf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJP2ylhAAoJEAfDBXDHBQilBj0H/AuUTW8jVPgglHHvrmRRRbX6
sYq/3QlMbbHqOOy0ziHz8ZtyeI/uBlz+zVUwFg0Dsu3enoWgmpQBTvsvCkCFpM++
8XCMHWiGdk6tgCz9/datWZkRXcqAv3xjwSsdCXuFaHDWsFyWwFPq3ze5uWL1IdMC
DHk605oB6VtKjfWT/4iU4nwEqFrGQOF4h/Sb2GrLYq01JNWot1BFeuYPRK5Iaugg
FH6BcZ4aXcC+9RBfyJp6CXzqzIpbcC4r8DMaujVrQAAXa+cuWPfa6eqdQMrLR+2J
BLCG/FqSZYtSyh77R/tQDzhgtXwCt+qX9ni4iPnOlRjh/nAgq+lC9gy5oZbwsf8=
=sXhZ
-----END PGP SIGNATURE-----

--=-PasPzxy3OL/GkSIsiDsf--