If you ask me, stick with creating the tables via the script even if the UI option is easily available (e.g. in Windows). Why? Because once you’re dealing with commands, you can easily add them to a script and transform your installation into a fully automated task. This is not only valuable from a productivity stand point but it greatly reduces the likelihood of errors or discrepancies across environments.
As far as what to install where, I typically create a database/schema for each product that is being installed, those being: BPM, IS, MWS, Optimize, and TN. So, in my databases, you will typically see these databases/schemas: wmbpm, wmis, wmmws, wmopt, and wmtn. Now that upgrades are officially supposed to be done side-by-side, I also started adding the version number to the end, e.g. wmbpm97, wmis97, etc. In addition to these product databases, I also create a database for the Archiving components and I name it wmarcXX, e.g. wmarc97.
You can then call the dbConfigurator script with the -pr option to install each product into their respective database.
Here’s a snippet extracted from a script that has been used in my current customer as part of a fully automated installation of the BPMS suite across 7 servers and multiple developer workstations:
dbConfigurator.bat -a create -d sqlserver -c storage -v latest -l jdbc:wm:sqlserver://wmdb;databaseName=master -u %DB_USER% -p %DB_PASS% -au %SA_USER% -ap %SA_PASS% -n wmopt
dbConfigurator.bat -a create -d sqlserver -pr OPTI -v latest -l jdbc:wm:sqlserver://wmdb;databaseName=wmopt -u %DB_USER% -p %DB_PASS%
Hope this helps,
Percio
#Integration-Server-and-ESB#webMethods-General#webMethods