Importing data from an External DB & Efficiency

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Sara

    Importing data from an External DB & Efficiency

    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
    "TransferSpread sheet" 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
  • Tom van Stiphout

    #2
    Re: Importing data from an External DB & Efficiency

    On 20 Nov 2004 06:36:04 -0800, saraqpost@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).
    TransferSpreads heet 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.


    [color=blue]
    >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
    >"TransferSprea dsheet" 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[/color]

    Comment

    • Marc

      #3
      Re: Importing data from an External DB & Efficiency

      saraqpost@yahoo .com (Sara) wrote in message news:<d9061747. 0411200636.42c3 925c@posting.go ogle.com>...[color=blue]
      > 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
      > "TransferSpread sheet" 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[/color]

      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 (Transferspread sheet) can be used and
      the update-process can be centralized and more easily automated.

      Marc

      Comment

      Working...