From derby-user-return-12662-apmail-db-derby-user-archive=db.apache.org@db.apache.org Sun Apr 25 17:44:27 2010 Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 7316 invoked from network); 25 Apr 2010 17:44:27 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 25 Apr 2010 17:44:27 -0000 Received: (qmail 66492 invoked by uid 500); 25 Apr 2010 17:44:27 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 66461 invoked by uid 500); 25 Apr 2010 17:44:27 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 66454 invoked by uid 99); 25 Apr 2010 17:44:27 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Apr 2010 17:44:27 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [74.6.228.83] (HELO n11.bullet.mail.ac4.yahoo.com) (74.6.228.83) by apache.org (qpsmtpd/0.29) with SMTP; Sun, 25 Apr 2010 17:44:18 +0000 Received: from [76.13.12.64] by n11.bullet.mail.ac4.yahoo.com with NNFMP; 25 Apr 2010 17:43:56 -0000 Received: from [74.6.228.80] by t5.bullet.mail.ac4.yahoo.com with NNFMP; 25 Apr 2010 17:43:56 -0000 Received: from [127.0.0.1] by omp1001.mail.ac4.yahoo.com with NNFMP; 25 Apr 2010 17:43:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 230006.94551.bm@omp1001.mail.ac4.yahoo.com Received: (qmail 96719 invoked by uid 60001); 25 Apr 2010 17:43:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s1024; t=1272217436; bh=t52Ly+Aw7olmD6uKomCfvGqmqVFmeOb7DTzU/TNQm5A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fNtmgq7SKP0c6vZFNfexpMZIQwaMYAo8veflWiWod7XbfjU6czrueo6MKA492lwT0o85T3tS+fGvhbM3WYsu3P2BZFfA4yv5v/mnalHX15xStOUU6ih4PRF9vlZrrQtNvewh6Y39O6MCsNFzIauM146ftzupKG1Bh9Szptlfng4= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=ymail.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=HMH7lSS9bqhtNQCBbMmoWoFVwKXMN2/fpQ+J4TvMQozFp3Yg3owV/CDUMF7U55Q96HriK9doNk2lbOBWxAC//6buelwJBbmXbY2pQSHf5Wa8z3qnFel2AetqIvmNRgRx63MI1ORLnuRHWNnt9AZTHNcjiAwAMcpYjUWtHiUMrp8=; Message-ID: <100352.95620.qm@web59504.mail.ac4.yahoo.com> X-YMail-OSG: pcEdBTIVM1npZLdRS_F8D.U4SyUhmCyX6dVAERE4DM.VWeE coJdG3g5G5.v7bisyaogJGYobw2RaVFghHeMKtpDvYYIZzqzb55ZcmS8Io2x Gb_hLkM0exVP0oky2.1DFEbUlF7IH.YJ54kh0TSGt78X7Vlr90B0ZyWd9ZWa aM_ctw6.MkHuuC2.rHWSyQyBXhFq6OEfpyvkdSm3WRVnoRDuYmmtDw0r7yCc xMRRWQVtWfrULlqM3HJYqimrzODTHdXDxHJM.Qg-- Received: from [122.168.25.30] by web59504.mail.ac4.yahoo.com via HTTP; Sun, 25 Apr 2010 10:43:56 PDT X-Mailer: YahooMailClassic/10.1.9 YahooMailWebService/0.8.102.267879 Date: Sun, 25 Apr 2010 10:43:56 -0700 (PDT) From: Dinesh Bajaj Subject: Re: Transfer data between tables that are located in different databases To: Derby Discussion In-Reply-To: <4BD453C7.2040201@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-260184518-1272217436=:95620" X-Virus-Checked: Checked by ClamAV on apache.org --0-260184518-1272217436=:95620 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bryan, Thanks for your response. I haven't written any code yet to implement this functionality, as I couldn= 't thought of a decent way to do this. I was mainly looking for a feature t= o initialize the target ResultSet from the source ResultSet and then updati= ng the target one to save the data in one go. I wanted to avoid the mundane= task of reading row-by-row from a source Resultset and then putting in the= target ResultSet. As it is a lot of data that needs to be transferred between tables, the ide= a of using the system procedures to export the data from the source table, = and then importing it in the target table appears to be good one. I will de= finitely give it a try, and will post the code here if I encounter any erro= r. Thanks again for your reply. -Dinesh --- On Sun, 25/4/10, Bryan Pendleton wrote: From: Bryan Pendleton Subject: Re: Transfer data between tables that are located in different dat= abases To: "Derby Discussion" Date: Sunday, 25 April, 2010, 8:07 PM > Could someone give me pointers on how to transfer data between two tables= that are identical in structure, but located in different databases. This = task needs to be accomplished through code. A single program can certainly have multiple databases open. Each java.sql.Connection object is tied to a single database, but you can have several Connection objects, each pointing to a different database, and switch back and forth between them in your program as you need to. If it's a lot of data, you could run the export/import system procedures. Export the data from the source table to a text file, then import it to the target table. If it's a small amount of data, you can open two connections in your program, read the data from the source table, and insert the data into the target table. Depending on how generic your transfer code needs to be, you could simply hard-code the names of columns and their data types in your code. Or, you could use the DatabaseMetaData classes to determine the column names at runtime and write a generic transfer routine. Why don't you post the code you've tried so far, and the problems you've encountered, and the community can then suggest solutions to those problems. thanks, bryan =0A=0A --0-260184518-1272217436=:95620 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Bryan,

Thanks for your response= .

I haven't written any code yet to implement this functionality, as= I couldn't thought of a decent way to do this. I was mainly looking for a = feature to initialize the target ResultSet from the source ResultSet and th= en updating the target one to save the data in one go. I wanted to avoid th= e mundane task of reading row-by-row from a source Resultset and then putti= ng in the target ResultSet.

As it is a lot of data that needs to be = transferred between tables, the idea of using the system procedures to expo= rt the data from the source table, and then importing it in the target tabl= e appears to be good one. I will definitely give it a try, and will post th= e code here if I encounter any error.

Thanks again for your reply.
-Dinesh

--- On Sun, 25/4/10, Bryan Pendleton <bpendleton.derby@gmail.com> wrote:

From: Bryan Pendleton <bpendleton.derby@gmail.com>
Sub= ject: Re: Transfer data between tables that are located in different databa= ses
To: "Derby Discussion" <derby-user@db.apache.org>
Date: Sun= day, 25 April, 2010, 8:07 PM

> Could som= eone give me pointers on how to transfer data between two tables that are i= dentical in structure, but located in different databases. This task needs = to be accomplished through code.

A single program can certainly have= multiple databases open. Each
java.sql.Connection object is tied to a s= ingle database, but you can
have several Connection objects, each pointi= ng to a different database,
and switch back and forth between them in yo= ur program as you need to.

If it's a lot of data, you could run the export/import system procedures.
Export the data from the source ta= ble to a text file, then import it
to the target table.

If it's a= small amount of data, you can open two connections in your
program, rea= d the data from the source table, and insert the data
into the target ta= ble.

Depending on how generic your transfer code needs to be, you co= uld
simply hard-code the names of columns and their data types in your c= ode.
Or, you could use the DatabaseMetaData classes to determine the
= column names at runtime and write a generic transfer routine.

Why do= n't you post the code you've tried so far, and the problems
you've encou= ntered, and the community can then suggest solutions
to those problems.<= br>
thanks,

bryan

--0-260184518-1272217436=:95620--