|
Archives of the TeradataForumMessage Posted: Thu, 01 Dec 2005 @ 10:27:25 GMT
Oh, I thought you were after the blocking process when the maximum number of load utilities is exceeded (i.e. the TENACITY parameter). The TABLEWAIT is about multiple loads to a single table. Nevertheless the technique should still work. I am guessing a little here, but I still think if you abort the first mload, this will release the lock that the tablewait is monitoring - but then the second mload will probably get the "table is being loaded error". So I would still go back to run an mload which is importing from a named pipe (Unix) or an INMOD that simply delays (Windows). Then fire off the second mload and see the delay messages. Then terminate the first mload (ideally gracefully) so that the second one may proceed. Here's a relevant tale from the war stories cabinet, I once corrected a spelling error in a comment in a script file. The "productionisation secret police" detected the change and wanted to see the test reports. diff demonstrated it was the only change from the production version, but they still wanted to see the test reports. Unfortunately for you it sounds like you are in a catch 22 situation, you have to change the production code to support the test. You can then demonstrate the code works as advertised (hopefully) - at which point you change it back and they say hang on you've changed the code etc. Good luck with it - sounds like you might need it! Glenn Mc
| ||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
Copyright 2016 - All Rights Reserved | ||||||||||||||||||||||||||||||||||||||||||||||||
Last Modified: 15 Jun 2023 | ||||||||||||||||||||||||||||||||||||||||||||||||