>>After a period a time(a few minutes, <g>the isapi server clearly unload this object. The server reload automatically but it is not active. All cached data have been release. It is in a "not available - call later" state.
>
>Yes, this is a known DCOM behavior. Any COM server idle for about 7-8 minutes will unload. FoxISAPI will reload it on the next hit, but in the meantime the server gets unloaded (ungracefully I might add - if a lot of these occur the COM system eventually gets corrupted).
>
>Again, I know of no workaround for this problem with FoxISAPI. In Web Connection this issue is addressed with a 'Keep-Alive' flag that keeps an extra phantom reference to the COM server which makes DCOM not unload it.
>
>>I clearly found no trick to prevent foxisapi to unload this dammed com object. the foxisapi /status say the object is there in cache but it is actually released (:
>>
>>We need support for this very heavy stateful object. Does west-wind connection provide this ability to lock the object in memory ? I am really willing to try your software.
>
>Yes it does...

Thanks a lot for the information.

I shall definitely try to hosting our objects in ISAPI with a "kept-Alive" Web Connection session.

By the way, this iis4-started object will automatically open up a db-connection at times. Do you know of a trick to secure the odbc connection info (user id+password) from hackers?

My current choice is limited to:
- embed the password in the com exe or dll (not a choice as it need to be changed often),
- put it - possibly encrypted - in an ini file probably in a secure place
(not available by the iusr).

Any more secure alternative to prevent unauthorised access to the db-server (a sybase anywhere engine)?

François