‎2009 Oct 15 1:33 PM
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.
‎2009 Oct 15 1:39 PM
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
‎2009 Oct 15 1:39 PM
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
‎2009 Oct 15 1:55 PM
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.
‎2009 Oct 15 2:02 PM
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
‎2009 Oct 15 2:25 PM
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
‎2009 Oct 15 2:30 PM
Hello Marcin,
Very well explained !!
10 p*ints from me
Cheers,
Suhas
‎2009 Oct 15 2:41 PM
>
> Hello Marcin,
>
> Very well explained !!
>
> 10 p*ints from me
>
> Cheers,
> Suhas
Thanks Suhas, I will virtually add them myself;)
Regards
Marcin
‎2009 Oct 16 4:54 AM
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.
‎2009 Oct 16 8:29 AM
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
‎2009 Oct 16 12:54 PM