Skip to main content
Hi there

 

 

I would like to use the WorkspaceRunner to start one Workbench several times through a published input-parameter (e.g. the database-connection details of a Oracle DB), e.g. for merging data from several political entities into one superior entity.

 

 

Therefore you have a Workbench that processes the input data and writes it to a table of a DB, a text file that contains the input parameters of the DB for the writer of the mentioned Workbench and a second Workbench consisting of a WorkspaceRunner. This WorkspaceRunner reads one line of input parameter after another and starts the workbench each time with the respective input.

 

 

This would not be a problem itself. The difficulty is that before/at each start of the Workbench containing the WorkspaceRunner, the table should get truncated once so that only the new set of data is contained. If you activate the 'Truncate Table First' format parameter of the writer, the table will be truncated at each run of the Workspace. So you have only the data of the very last call of the Workbench in the DB table.

 

 

Is there any possibility to specify that only at the first run of the Workbench initiated by the WorkspaceRunner this truncation takes place?

 

 

The only possibility offered in FME that comes to my mind is to expand the Workbench that contains the WorkspaceRunner in a way, that an equally defined but empty table of the DB is called by the reader and gives its 'empty' content to the writer with activated truncation. This process would be executed only once. But I am not sure if one can assure that this truncate-process will be called always before the WorkspaceRunner

 

 

 

 

Hi,

 

 

rather than using the "Truncate table" option on the writer, consider doing the truncate with an SQLExecutor. You can then control whether to do the truncate with e.g. a Tester.

 

 

David
Hi,

 

 

Another approach. You can create a published parameter linked to the "Truncate Table First" parameter. Then, specify "YES" at the first run, "NO" at other runs to the parameter via the WorkspaceRunner.

 

 

Takashi
Hi,

 

 

Thanks for your inputs and sorry for my absence!

 

 

Takashi, your solution worked and needs only moderate adjustments of the already existing workspaces, thank you very much!

 

 

I also tried the approach with the SQLExecutor including the statement 'Truncate Table ...'. It was palced between the Reader (a CSV file) and the WorkspaceRunner. The intention was that it performs the truncate and passes the input data of the CSV unaltered to the WorkspaceRunner. But the SQLExecutor does not transmit these data, no matter what values I choose for the parameter of the transformer.

 

 

Since I have now a working approach it is not critical anymore to get a solution for the SQLExecutor approach but it would be interesting nevertheless. Does SQLExecutor need additional SQL statements to handle the input text data?

 

 

André

 


Hi,

A bit late to the game on this one but...

I have a WorkspaceRunner that creates about 15 tables of gaps and slivers that cannot be truncated between calls. The WorkspaceRunner could potentially be called 360 times from the main Workbench for all the areas I'm testing. My solution was to add a Startup script in the main Workbench that used arcpy.Delete_management (theTableToDelete) to remove any table the WorkspaceRunner creates and writes to. That way, I know I'm starting with a fresh newly-created empty table the first time the first WSR is called and writes to the database.


Reply