Well,
I just re-read in the documentation and yes, load with cursor appears to be a valid option.
You declare the cursor and open it and then using it as input for load sounds do-able with federation. Unfortunately I forgot to test that when fooling around with II, I'll sure give it a try next week.
I have no idea about performance. I mean the load can't be faster than the extract and network, but this will be very fast.
With federation you actually are able to create an MQT locally based on remote table data. Then overnight you could do a refresh - and there you are. Still - I have no idea how long the recalculation takes, but it is an option to copy the data. Performance would be a point to try out as well. And I have no idea whether this is actually logged or not ...
when you have a licence also for II replication and MQ, then you could give replication a try.
That is asynchronous reading the logfiles, and MQ is a really fast and safe pump. Setup is easier than expected, but of course licence fees are quite huge ....
SQL replication is not bad either, and asynchron as well. And they did quite a job on making it more robust and faster. Even the setup tools and GUIs in V8 actually can be used now ... ;-) So this is a similar option without MQ.
Replication is good from technology point of view, but it is expexive in licenses.
You have to automate with flat files anyway, so why not using db2move or extracting the data using export and pumping it using load ? I can't see the point why in the first place you have to use Access in between at all. I mean you need the client anyway for the ODBC interface, then you can export there as well directly and load it into the local db2 ? This would not avoid flat files, but it avoids Access at least.
Juliane