32/64 bit Application Platform

AETLE/P v3.6.11.19

Developer: ATELP x32
Production Runtime: AETLE x64

Hi, I wanted to just raise this even though I suspect it would be difficult to replicate at your end. However, it did cause us some grief and thought you should be made aware of it.

Basically, I had setup a scheduled package to run on our server (AETLE x64) via my developer instance of AETLP (x32). The problem was that even though I had nominated the server's name as the runtime platform I had neglected to change the Application Platform setting from x32 to x64. Then when the server ran the task, we ended up getting numerous process instances of aetlcl.exe evoked but never killed off. This eventually ground the server to a halt and almost crashing.

A similar but less impactful instance was where I had setup a monitored event indicating that the Server Node to run on was our server, again from my Professional AETL was used and, 'yes' I forgot to change the Application Platform from x32 to x64. The result was that the monitor event was triggered and the packaged was submitted to the queue - but it would never transition to 'executing' and would remain as 'submitted'. 

I realise that in both cases my neglecting to change the platform resulted in both situations. However, I was wondering if there was some way to either make this (in our case) a mistake more obvious or provide a default that can be setup initially and then overridden on a case-by-case basis. I understand it is probably there for 32bit ODBC driver support. But in our case, it would be really good to set and forget as we don't have any 32bit drivers on the server and the only one we would need x32 for is an Access Driver but that is only on the developer Professional Edition and is very rare.

 

Cheers
Bruce

I think the easiest way to deal with it is to add default to the options dialogue

There is another aspect of it as well the 64-bit version should be able to run 32-bit as well (Provided that you have all the drivers)
(32-bit aetcl.exe is stored in a separate folder)

Sure. However, a suggestion might be to extend the Nodes table to include a Platform Architecture column that could be filled in via whatever mechanism you currently populate it. Then when the schedule or monitor is setup and the node is entered then a lookup could be done to prepopulate a default value for the platform. Not sure how much of a breaking change that would be but we have to run DML scripts now to add new data elements so why not a DDL to add the column? I know much to consider but it would be a more integrated solution. CHeers

Modifying the repository brings a lot of problems to existing customers. So we will modify the options dialogue.

Hi Bruce

Just letting you know that your suggestion was implemented in the latest release

 

Thanks for the update