Can I import SAP tables that were exported by SE16?

Question

I have exported the contents of a table with transaction SE16, by selecting all the entries and going selecting Download, unconverted.

I'd like to import these entries into another system (where the same table exists and is active).

Furthermore, when I import, there's a possibility that the specific key already exists for a number of entries (old entries).

Other entries won't have a field with the same key present in the table where they're to be imported (new entries).

Is there a way to easily update my table in the second system with the file provided from the first system? If needed, I can export the data in the 3 other format types (Spreadsheet, Rich text format and HTML format). It seems to me though like the spreadsheet and rich text formats sometimes corrupt the data, and the html is far too verbose.

[EDIT] As per popular demand, the table i'm trying to export / import is a Z table whose fields are all numeric, character, date or time fields (flat data types).

I'm trying to do it like this because the clients don't have any basis resource to help them transport, and would like to "kinna" automate the process of updating one of the tables in one system.

At the moment it's a business request to do it like this, but I'm open to suggestions (and the clients are open too)

Answer 1

Edit

Ok I doubt that what you describe in your comment exists out of the box, but you can easily write something like that:

Create a method (or function module if that floats your boat) that accepts the following:

iv_table name TYPE string and
iv_filename   TYPE string

This would be the method:

method upload_table.

  data: lt_table     type ref to data,
        lx_root      type ref to cx_root.

  field-symbols: <table> type standard table.

  try.

      create data lt_table type table of (iv_table_name).
      assign lt_table->* to <table>.

      call method cl_gui_frontend_services=>gui_upload
        exporting
          filename            = iv_filename
          has_field_separator = abap_true
        changing
          data_tab            = <table>
        exceptions
          others              = 4.

      if sy-subrc <> 0.
        "Some appropriate error handling
        "message id sy-msgid type 'I'
        "     number sy-msgno
        "     with sy-msgv1 sy-msgv2
        "          sy-msgv3 sy-msgv4.
        return.
      endif.

      modify (p_name) from table <table>.  
      "write: / sy-tabix,  ' entries updated'.

    catch cx_root into lx_root.
      "lv_text =  lx_root->get_text( ).
      "some appropriate error handling 

      return.
  endtry.

endmethod.

This would still require that you make sure that the exported file matches the table that you want to import. However cl_gui_frontend_services=>gui_upload should return sy-subrc > 0 in that case, so you can bail out before you corrupt any data.

Original Answer:

I'll assume that you want to update a z-table and not a SAP standard table.

You will probably have to format your datafile a little bit to make it tab or comma delimited.

You can then upload the data file using cl_gui_frontend_services=>gui_upload

Then if you want to overwrite the existing data in the table you can use

modify zmydbtab from table it_importeddata.

If you do not want to overwrite existing entries you can use.

insert zmydbtab from table it_importeddata.

You will get a return code of sy-subrc = 4 if any of the keys already exists, but any new entries will be inserted.

Note There are many reasons why you would NOT do this for a SAP-standard table. Most prominent is that there is almost always more to the data-model than what we are aware of. Also when creating transactional data, there are often follow-on events or workflow that kicks off, that will not be the case if you're updating the database directly. As a rule of thumb, it is usually a bad idea to update SAP standard tables directly.

In that case try to find a BADI, or if that's not available, record a BDC and do the updates that way.

Answer 2

If the system landscape was setup correctly, your client would not need any kind of basis operations support whatsoever to perform the transports. So instead of re-inventing the wheel, I'd strongly suggest to catch up on what the CTS and TMS can do once they're setup with sensible settings.