Hello,

We don't use BaaN-Finance, but data are nevertheless written in table tfgld (now big tables).
I don't want to set up a procedure of archiving.
Can I delete records in tables tfgld410,418,415,417 (records for years 2001 and 2002 for example) ??

Thank you very much.

Hello,

We do that since years, our tfgld410 table had more than 15,000,000 lines ...

We are using Baan Finances, but are deleting the non project records for a lot of tror/fitr.

For our subsidaries which dont't use financial integration, we only keep sales/invoice and purge all other records.

Regards

PS: solution to win diskspace, if you are in level 2 and don't use dimensions you can delete tfgld106 index4 to 8.

Thank You for answer.

What is the best way to purge data for these tables ?
- dump table, then remove lines in text file, then create table from dump.
- gtm
- oracle (sql)
- ??????

I need to have your opinion.
Thank you.

My colleague just created a code to remove not for finance pcs trx from integration . Though this is untested , there is no reason why it should not work.

Hi Clarisse

I think you can use the archiving session(tfgld4210m000) just to purge the data without even setting up a archiving company.

We customized the Baan standard archiving session to write the data from these integration tables to flat files before the records are deleted.

Suresh

Beware of the fact that allthought you don't need the transactions in your GL, the transactions are needed to calculate the results on your projects. If you don't need that you can easily delete a lot of int. transactions.

Indeed the code must be untested as it will fail on Oracle when having a large range. The application will fail with an ORA-1555 (Snapshot too old). I suggest you to do the following:

long finished

finished = false

db.retry.point()

repeat
select*
from for update
as set with 10000 rows
selectdo
|your stuff here
selectempty
finished = true
endselect
until finished
This code is also untested and only works here because we delete records. There are more ways to do this, but this works here ;)

Kind regards,
Dick

You can also add a 'as prepared set' above the selectdo. It's a bit slower but you avoid the snapshot too old.

Adding the "as prepared set" is not working here as the query selects the table in "for update" mode.

Kind regards,
Dick

Thanx Dik,

Never too old to learn...

ONNO

Also learned this by a failing session ;)

I did test the code later on . Only db.retry.point() was missing. Then it worked fine for us. Nevertheless good tip. Thanks.