Welcome to Tony's Education Corner. :) Most of the responses so far say "connect, do your stuff, then disconnect". That's all good advice - here is why people are saying this.
This is the concept of Persistence. If you hold a connection between user inquiries, you have a Persistent connection. If you do not hold the connection, it is Non-Persistent, but then you need to work out how you are going to manage State. That is the state of a user session, user variables that tell the application where a given user is at any given time. State can be managed on the server by writing variables do disk with a unique ID, then passing that ID back to the client program. When the user re-connects, the ID is provided, the app reads the state variables, and continues where it left off. (In the .NET world, this is called Serialization.) State can also be passed back entirely to the client. If the users are coming in from a browser, you might need to maintain state at a middle-tier, like on a web server, and pass the unique ID back in a cookie. There are many ways to architect solutions like this. If you want to consume a minimal number of licenses you need to code a minimal persistence and effective state management. The effectiveness of this, and therefore the real number of concurrent licenses required, is entirely up to you. One thing you want to be careful of: Don't allow users to do a Sort or Select on a large file, or otherwise initiate a process that will take over 30 seconds to process. This will tie up the connection, and if the user gets impatient they may terminate the process. Long-duration processes can be done by a background task and the user should be given a means for checking on the status of open jobs - or you can e-mail them when reports are ready, etc.. Remember that you want to return a response back to the user as soon as possible. Some applications go into a status-check loop where the client checks for job completion, and if the job is not done the user sees a progress bar or some other entertainment - though the connection appears to be persistent, it's not. Be sure to account for the "no license" condition in client code. The client should be able to retry some number of times or for some time duration before reporting back a connection failure to the user. The client code should pass back this sort of information to the server when it finally does connect. With this information you can add more licenses or make code optimizations as required. Without this information you may not know just how overloaded your connections are. I have extensive experience with writing interfaces like this, and I'll be happy to provide services to help with any such project. My preferred tools these days for MV connectivity are the Pick Data Provider .NET from Raining Data, and DesignBAIS, but the server-side is coded pretty much the same for any tool including UniObjects. Good Luck, Tony Nebula R&D [EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Fawaz Ashraff > Sent: Tuesday, July 13, 2004 6:46 PM > To: [EMAIL PROTECTED] > Subject: [U2] UniObject Licening > > Hi All, > > We are trying to use UniObject for UniData to get > information for various web projects. Most of the > Front End is done using VB .Net. It looks like > UniObject is using a user license for each connection. > There would be thousands of students using this > application and we are having a licensing issue. > Should we structure our program differently? Has > anyone else come a cross the same problem? If so what > did you do? > > Thanks a lot. > > > Fawaz ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
