Citrix

Is there a process that can be used when running on Citrix that would guarantee that you run the "current" version? Something like you always check it out first, then erase checkout, then submit?[crazy]

Tricia,

Glad to see you back on the list.

Warning *** Crazy Experimental Concepts ***

Another question like this came up today when it was asked if language overrides could be applied to the version name in the batch version application. My thought was sure it is possible but it will involve modifying the batch versions application to link in another table that holds the translated names.

I think of the same type of thing in regards to your question. I could see a modification to the app that launches UBE's so that it would perform JITI before launching the report. It would be much more difficult with interactive applications because they are launched by the OneWorld Foundation Code.

All of the above is just me musing. While it might be possible I would never recommend it in a production environment. JITI is to be avoided on the Citrix Server because the TAM files and the objects within those TAM files are shared. Until JDE actually puts a transactional mechanism into the TAM format you cannot reliably check-out, JITI or otherwise update the TAM files in a Citrix environment with more than one active user

Is the motivation for your question that you looking for a better way to manage update package deployment to a Citrix farm?

Regards,

Exactly, that is the motivation for my question. We will begin utilzing Citrix more with our field employees and this question came up. Do you have the answer or suggestions on a better way to manage the update package deployment with a Citrix farm .

After reviewing the response, I wonder if one user, after hours, when no one else is on Citrix, could check out an updated object and then erase the checkout. This would update the Citrix TAM file. We would have to be careful of user-generated versions, which it sounds like could be a problem with Citrix users anyway.

I would agree that you could do this after hours with a check out. This would of course not address updates to business functions. The package deployment method is probably the best approach for production maintenance.

The problem with users creating batch versions on a farm is that if they do not check them in before disconnection they may not log into the same server the next time they connect and will then be unable to check the versions in. I have allowed version creation on a limited basis during the CRP period with an instruction that versions were to be checked in before the user disconnected. It saved me from having to put evil fat clients on desktops for project members who were only doing batch version creation. Interactive version creation is never a problem as there is no check out/check in needed.

Regards,