Why not use Get External Data?

[Cameron Tully-Smith]

I've been told not to use Get External Data. This is for a database that is
1.99GB and compacting down to 127MB (routinely ending up back at 1.99GB).

How does Get External Data differ from importing the same rows using an
append query?

Thanks,

Cameron

 

[Peter Russell]

I've been told not to use Get External Data. This is for a database
that is
1.99GB and compacting down to 127MB (routinely ending up back at
1.99GB).

How does Get External Data differ from importing the same rows using an
append query?

Thanks,

Cameron

What is your external data?

It can be simpler to link to external sources rather than import them.
You still use GetExternalData but use the Link option rather than the
import.

Regards

Peter Russell

 

[Cameron Tully-Smith]

The data is another Access database. The idea is to build up a new Access
database from an existing one (this has fixed some problems in the past),
but I've been told not to use Get External Data (the usual method).

 

[Douglas J. Steele]

Did whoever told you not to use Get External Data offer any suggestion why
not, or an alternative?

 

[Alick [MSFT]]

Hi Cameron,

Get External Data is a useful functionality; it contains two kinds of
methods: importing and link tables. From the menu, we can see File->Get
External Data menu, there are two sub-menus under Get External Data menu:
importing, link tables. Therefore, it not suitable to compare Get External
Data with importing, importing belongs to Get External Data.

If you mean other importing, such as a query that imports data from
external data source, Get External Data already can do that for you. If you
have some specify scenario that prevents you from using Get External Data,
would you please post the detailed situation and the reasons why it
prevents you from using Get External Data functionality?

Please feel free to reply to the threads if you have any concerns or
questions.



Sincerely,

Alick Ye, MCSD
Product Support Services
Microsoft Corporation
Get Secure! - <www.microsoft.com/security>

This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
| From: "Cameron Tully-Smith" <[email protected]>
| Newsgroups: microsoft.public.access.conversion
sjc72.webusenet.com!news.webusenet.com!feed.news.sonic.net!typhoon.sonic.net
!not-for-mail
| Xref: cpmsftngxa06.phx.gbl microsoft.public.access.conversion:38520
| X-Tomcat-NG: microsoft.public.access.conversion
|
| I've been told not to use Get External Data. This is for a database that
is
| 1.99GB and compacting down to 127MB (routinely ending up back at 1.99GB).
|
| How does Get External Data differ from importing the same rows using an
| append query?
|
| Thanks,
|
| Cameron
|
|
|

 

[david epsom dot com dot au]

'Get External Data' is more likely to import
corruption from a corrupt file than is a
Jet 'Create Table' Query.

Even a Jet 'Create Table' query can import
corruption from a corrupt file.

The BEST way to avoid importing corruption
(although seldom necessary) is to rebuild the
tables by hand, from nothing. This way,
your tables, indexes, and relationships
will be clean.

Then import only the data, using an Append
Query. The append query will normally fail on
bad data, and normally will not corrupt your
clean tables, indexes, and relationships.

(david)

 

[Cameron Tully-Smith]

Thanks, this answers my question.

'Get External Data' is more likely to import
corruption from a corrupt file than is a
Jet 'Create Table' Query.

Even a Jet 'Create Table' query can import
corruption from a corrupt file.

The BEST way to avoid importing corruption
(although seldom necessary) is to rebuild the
tables by hand, from nothing. This way,
your tables, indexes, and relationships
will be clean.

Then import only the data, using an Append
Query. The append query will normally fail on
bad data, and normally will not corrupt your
clean tables, indexes, and relationships.

(david)

 

[david epsom dot com dot au]

technical note: where i wrote "Create Table",
i meant "Make Table".

(david)