We have users in non-finance groups that we want to give access to the blocking of invoices in tfacp200 but we don't want to allow them to modify all records. Also, we don't want to use DB level authorizations. So, I am attempting to create a session that will allow them to modify just the records in tfacp200 where bloc is not null, by using skip.io in the main.table section of my code. It works great except the tfacp200 table has 530K+ records in it so if you hit the first or last button it can take 5 minuts + to get a response.

Is there a way to speed this process up?

Right now the code looks like this:
main.table.io:
after.read:
get.blck.desc()
if (isspace(tfacp200.bloc)) then
skip.io("")
endif

I would like to be able to create a session similar to tfacp2532m000 (display registered invoices) except as a maintain session and I thought about copying the code and modifying it (but we do not have source).

Hi,

I think you can use the query extension.

I found a script that used the query.extension and modified my code to look like this:
before.program:

string q(1)
string xtn(20)

q = chr$(34)
xtn = "tfacp200.bloc <> " & q & q

query.extension = xtn

and now it only takes about 1 minute to go through the entire list of 530K+ records.

Thanks,

You might want to try to include the field 'bloc' to an index in tfacp200 and then use that index for your session. Then use the query.extension as before and I think you'll see a significant performance improvement.

Neil Pengelly

Thanks for the suggestion, but I have one additional constraint - "don't modify existing Baan objects". My manager is adament about leaving Baan as is, and only doing "personalizations" (and table mod's are a definite no-no). :rolleyes:

Thanks though.

Consider generating your own maintain session. This will allow you to control actions using your own code. Create an index on the block code and reference this index in SQL thus excluding records that you do not want them to edit. No database authorizations will be required for this approach.

We had similar problem with the unblocking of sales orders. Users accidently selected either first or last record and the system would take an unacceptable amount of time to respond. Since I put index on table, there have been no more complaints ABOUT THIS PARTICULAR PROBLEM. Ha!