topic Re: Saving Data Objects in INDX-Type Database in Application Development and Automation Discussions

Saving Data Objects in INDX-Type Database

Former Member — Thu, 15 Oct 2009 12:33:25 GMT

Hi,

I am using the EXPORT statement to store data in a table into INDx table.

EXPORT gt_update TO DATABASE indx(tt) ID index.

And then I am using IMPORT statement to get that data.

IMPORT gt_update to tb_update FROM DATABASE indx(tt) ID 'TTUPDATE'.

The 'TT' is put into INDX- RELID and 'TTUPDATE' into INDX-SRTFD.

The Export statement was working fine and a record got created in INDX table, but the IMPORT is not working. Can anyone please let me know what could be the problem ?

'gt_update' and 'tb_update' are of the same type in the IMPORT statement.

Also please let me know what exactly is the significance of the field INDX-SRTF2.

Thanks a lot in Advance.

Re: Saving Data Objects in INDX-Type Database

SuhaSaha — Thu, 15 Oct 2009 12:39:49 GMT

Hello,

In the EXPORT you are using ID = variable INDEX. Does INDEX = 'TTUPDATE'?

EXPORT gt_update TO DATABASE indx(tt) ID index.

But in the IMPORT you are using ID = TTUPDATE:

IMPORT gt_update to tb_update FROM DATABASE indx(tt) ID 'TTUPDATE'.

After EXPORT just go to INDX table & check what value has been updated in INDX.

You have to IMPORT using the same param. The important elements are RELID & SRTFD.

BR,

Suhas

Re: Saving Data Objects in INDX-Type Database

Former Member — Thu, 15 Oct 2009 12:55:25 GMT

Yes, index does contain 'TTUPDATE'. I had initially used index in the IMPORT statement too, but as it was not working, I had changed that to 'TTUPDATE'.

Also in INDX , RELID got updated as TT and SRTFD got updated as TTUPDATE. And I am using the same values of these two fields in the IMPORT statement.

The strange thing is the sy-subrc was equal to zero for the IMPORT statement but the table was empty!

Please help..what could be the problem ?

Thanks in Advance.

Re: Saving Data Objects in INDX-Type Database

SuhaSaha — Thu, 15 Oct 2009 13:02:18 GMT

Hello,

I think then there is something wrong in the IMPORT / EXPORT stmt.

If you do an F1 on IMPORT TO / EXPORT FROM DATABASE stmt, you will see a sample code. Which is a bit different from the way you have coded.

DATA: lwa_indx  TYPE indx.

EXPORT gt_update = gt_update TO DATABASE indx(tt) FROM lwa_indx  CLIENT sy-mandt ID 'TTUPDATE'.

IMPORT gt_update = tb_update FROM DATABASE indx(tt) TO lwa_indx  CLIENT sy-mandt ID 'TTUPDATE'.

Anyways in the table INDX, what is the value in the field CLUSTR? Is it greater than 0?

BR,

Suhas

Re: Saving Data Objects in INDX-Type Database

MarcinPciak — Thu, 15 Oct 2009 13:25:50 GMT

Two possibilities I think of:

- first one, the export table is empty, so the import one is also empty

- as Suhas noticed, this can be an issue of the way how you export/import table itself

It is the best always to threat impot/export parameter as it would be parameter of FM.

Durign FM call you always use such template


CALL FM ....
  EXPORTING 
      ex_param   = your_param

  IMPORTING
     im_param     = your_param

ex_param is the name which will be used in memory to store your_param

im_param should be therefore the same name as you MUST address the same param in memory and copy back to your_param

Assuming above, in both cases ex_param/im_param should be gt_update , you_param name can only change.

For EXPORT/IMPORT it would be then


EXPORT gt_update = your_table_with_data TO DATABASE indx(tt) ID 'TTUPDATE'.
 
IMPORT gt_update = your_empty_table FROM DATABASE indx(tt) ID 'TTUPDATE'.

As for the field SRTF2 it is jsut a counter of lines. If data don't fit one line, it will automatically spread over several ones. In this case SRTF2 will hold current line number.

Hope this helps

Regards

Marcin

Re: Saving Data Objects in INDX-Type Database

SuhaSaha — Thu, 15 Oct 2009 13:30:37 GMT

Hello Marcin,

Very well explained !!

10 p*ints from me

Cheers,

Suhas

Re: Saving Data Objects in INDX-Type Database

MarcinPciak — Thu, 15 Oct 2009 13:41:24 GMT


> Hello Marcin,
> 
> Very well explained !! 
> 
> 10 p*ints from me 
> 
> Cheers,
> Suhas

Thanks Suhas, I will virtually add them myself;)

Regards

Marcin

Re: Saving Data Objects in INDX-Type Database

Former Member — Fri, 16 Oct 2009 03:54:47 GMT

Hi Marcin/ Suhas,

Earlier when I was passing gt_update in the EXPORT statement, I did not get any data into gt_update. I was under the impression that when I pass it that way all the data in the table would go into the INDX table ( Which I feel now is very silly of me to think that way!).

EXPORT gt_update TO DATABASE indx(tt) ID 'TTUPDATE'.

Any ways now I have now written a SELECT to get data into gt_update and the IMPORT statement does work.

My reason for using data clusters is that there is huge amount to data to be retrieved from database, so we have decided to get that data and put it in data clusters for faster access of data in the program.

But I have a doubt, Ideally we should be having another program with the SELECT statement on the table required which needs to be scheduled periodically as a background job to Update the data cluster right ? Otherwise how would the data cluster hold the latest data ?

Please answer this one doubt, I can then close this thread by awarding the points

Thanks a lot.

Re: Saving Data Objects in INDX-Type Database

MarcinPciak — Fri, 16 Oct 2009 07:29:19 GMT


My reason for using data clusters is that there is huge amount to data to be retrieved from database, so we have decided to get that data and put it in data clusters for faster access of data in the program.

INDX tables are ideal to store complex strcutures, inlcuding deep data objects. Don't really know if the access is faster, but definitely it takes less space (as data are compressed).


But I have a doubt, Ideally we should be having another program with the SELECT statement on the table required which needs to be scheduled periodically as a background job to Update the data cluster right ? Otherwise how would the data cluster hold the latest data ?

It really depends on where you initial data comes from. I mean how data you want to put/update in data cluster are produced. If this is the report, which generates some result and based on that you want to update data cluster, then what you say is true. You would need to run it either manually (periodically) or simply schedule the job, which does the task.

But as for the update of data cluster itself, I don't think we should use OPEN SQL statements to achieve that.

What I think you have to do is, each time do a select to know which cluster to extract, then import the result. Next you need to change gt_update locally and place it back (with export) on right data cluster place. Data with same name under same RELID and cluster key will be completely replaced with new (changed) table.

This is the only way I think of in terms of data cluster update, but maybe there is some other.

Regards

Marcin

Re: Saving Data Objects in INDX-Type Database

Former Member — Fri, 16 Oct 2009 11:54:20 GMT

Thanks for the responses. Thread Closed.