By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,686 Members | 2,708 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,686 IT Pros & Developers. It's quick & easy.

Importing data from an External DB & Efficiency

P: n/a
Hi -
I've been reading the posts for a solution to my query, and realize
that I should ask an "approch" question as well.

We receive our production data from a third party, so my uers import
the data from Excel into the appropriate tables. There are 6
different databases that receive data, though 4 of them only get one
table each.

I have learned how to automate the data import through
"TransferSpreadsheet" and it works great. I have the user type in the
date for import from their daily form, and I go out to the server and
find all the files to import for that date.

My question relates to how I can import data to the other 4 databases
(one external db's table is already linked in the db with the form)
from this one. It will make the most sense to just have the user type
in the date once per day and click on "Import Data". The question is
how to do that.

I chose NOT to link the tables from the other 4 databases, as I don't
use that data at all in this database, and I figured it would be
inefficient, or make the .mde too big or something. So, I was looking
for code to allow me to import into a table that is in another
database and not linked in the current application. As I read the
posts, however, I see that maybe the best solution is to link the
tables? Maybe it doesn't impact efficiency, speed, etc.?

Those are my questions: Does linking impact efficiency? Should I
link or code? What command/code is used to import to a table in an
external Db?

Thanks in advance -
Sara
Nov 13 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
On 20 Nov 2004 06:36:04 -0800, sa*******@yahoo.com (Sara) wrote:

There is a difference between importing and linking. In your case,
linking is good, importing is not. A link takes only a few bytes (to
hold the definition of the table structure and the location), so
overhead is minimal.
You link a table manually (File/Get External Data) or through code
(Connect, RefreshLink).
TransferSpreadsheet can be used to import into tables as well as into
linked tables. That's the route I would take. Efficient enough in the
vast majority of situations.

-Tom.
Hi -
I've been reading the posts for a solution to my query, and realize
that I should ask an "approch" question as well.

We receive our production data from a third party, so my uers import
the data from Excel into the appropriate tables. There are 6
different databases that receive data, though 4 of them only get one
table each.

I have learned how to automate the data import through
"TransferSpreadsheet" and it works great. I have the user type in the
date for import from their daily form, and I go out to the server and
find all the files to import for that date.

My question relates to how I can import data to the other 4 databases
(one external db's table is already linked in the db with the form)
from this one. It will make the most sense to just have the user type
in the date once per day and click on "Import Data". The question is
how to do that.

I chose NOT to link the tables from the other 4 databases, as I don't
use that data at all in this database, and I figured it would be
inefficient, or make the .mde too big or something. So, I was looking
for code to allow me to import into a table that is in another
database and not linked in the current application. As I read the
posts, however, I see that maybe the best solution is to link the
tables? Maybe it doesn't impact efficiency, speed, etc.?

Those are my questions: Does linking impact efficiency? Should I
link or code? What command/code is used to import to a table in an
external Db?

Thanks in advance -
Sara


Nov 13 '05 #2

P: n/a
sa*******@yahoo.com (Sara) wrote in message news:<d9**************************@posting.google. com>...
Hi -
I've been reading the posts for a solution to my query, and realize
that I should ask an "approch" question as well.

We receive our production data from a third party, so my uers import
the data from Excel into the appropriate tables. There are 6
different databases that receive data, though 4 of them only get one
table each.

I have learned how to automate the data import through
"TransferSpreadsheet" and it works great. I have the user type in the
date for import from their daily form, and I go out to the server and
find all the files to import for that date.

My question relates to how I can import data to the other 4 databases
(one external db's table is already linked in the db with the form)
from this one. It will make the most sense to just have the user type
in the date once per day and click on "Import Data". The question is
how to do that.

I chose NOT to link the tables from the other 4 databases, as I don't
use that data at all in this database, and I figured it would be
inefficient, or make the .mde too big or something. So, I was looking
for code to allow me to import into a table that is in another
database and not linked in the current application. As I read the
posts, however, I see that maybe the best solution is to link the
tables? Maybe it doesn't impact efficiency, speed, etc.?

Those are my questions: Does linking impact efficiency? Should I
link or code? What command/code is used to import to a table in an
external Db?

Thanks in advance -
Sara


Sara,

The difference between importing into internal and linked tables is
negligable if the databases reside on the same machine. On a LAN the
difference often is also very small, but when the machines have to
cummunicate over slower or very busy network-links the performance can
drop dramatically. Linking a table on a LAN is easy and in most cases
very efficient. The linked table approach is also very easy because
ther is no difference in importing into existing native or linked
tables. The same macro-commands (Transferspreadsheet) can be used and
the update-process can be centralized and more easily automated.

Marc
Nov 13 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.