Hi,

Are there any known pitfalls that I should be aware of when running multiple WebConnect EXEs for the same website on the same server?

If it helps, I'm using IIS 10, I use file mode, and the data is stored locally.

Thanks, Chris

If you run in File Mode it should work fine. Just start up each instance and make sure each instance has its own folder for the temp files to look for incoming request meta-data. If you're using a recently created project - apps are completely isolated with their own relative paths for the temp folder and Web site, so you literally should just be able to copy the entire site and run it from there once you configure a custom Web site or virtual.

OTOH, running multiple COM instances of the same application is much more difficult. The problem there is that a COM server that is your application can only be registered to a single file location. There are some ways around that but it's ugly and involves basically creating a secondary application(s) for each instance with a different server name that can be registered separately.

+++ Rick ---

Thank you for your reply Rick.

Apologies for my lack of understanding, but I'm not sure what temp folder I need to change? I tried changing the "temp" path in the server status window, but this updates all other instances (after reloading each instance).

At the moment, I have 4 simultaneous EXEs running (all using identical settings), and it appears to be working, but every now and then one of the EXEs will get the 'Select Table' window popup, which stops that instance from running. I only get this issue when running multiple instances, never with a single instance.

Thanks, Chris

Not sure I follow what you're saying.

If you want separate applications, each application needs it's own installation and configuration.

+++ Rick ---

I'm trying to run multiple versions of the same EXE from the same server session (i.e. dbl-click the exe to run it once, then dbl-click it again to load the 2nd copy, and so on). I've attached a screenshot if that helps.

The reason I want to do this is to create multiple channels that will deal with the incoming requests (all for the same Web-App), it works well but I occasionally get the error I mentioned in my previous post.

I'm not sure if this is how WebConnect is intended to work, I'm open to ideas if there is a better way to achieve the same result?

Not sure what you mean by multiple channels?

If you want to be able to process multiple requests simultaneously, then yes you can just run multiple instances - or better yet let WWWC automatically start multiple instances via the autostart count in the server configuration - you can configure the number of instances that are automatically started. If you run in COM they will be automatically started and re-started if one crashes. File based can auto-start instances but not detect when instances crash.

As to the data error you're getting - that's to be expected since you are now essentially running a multi-user application with multiple instances potentially accessing the same data simultaneously. You need to make sure you set up your file sharing and error handling correctly (with retries) so that file access locks don't cause the application to hang or crash.

The most important ones are:

SET EXCLUSIVE OFF
SET REPROCESS TO 1 SECOND

Unhandled locking errors in file based will throw an error dialog. In COM you can use SYS(2335,0) to treat these as non UI errors that fail, but that doesn't work in File mode which always throw an error dialog if these errors are not handled.

+++ Rick ---

Thank you so much for your advice Rick. I do use data in SHARED mode, and I also use RLOCK() to protect against locking issues, although I have also added your 'SET REPROCESS TO 1' suggestion.

What appears to have solved my issue, is a suggestion from Tore Bleken, which was to add 'SET TABLEPROMPT OFF'. Since adding this line the error has not occurred.

Again thank you for all your help as always.

Regards, Chris

Hi Chris, I'm very happy to hear that my advice seems to have solved your problem.