You don't need to incur the network traffic issues of pulling all of your data from the DBMS server into another remote system. mv.NET is a thin transport that will execute your BASIC program as fast as it can run to generate your data, so that part incurs virtually no overhead. You can probably use the exact same BASIC program you have to generate your data, but data must be saved in Named Common, since mv.NET won't share common variable space with your apps. From then on, any process that hits that same port will have access to your common, just like it works now.
However... In a multi-user environment you may have multiple users hitting a single port at different times. If you do not want this form of contention then you must set a profile so that each user only uses a single login session, just like we do with telnet. If you allow users to share a pool of ports then you can't guarantee that one user will leave and come back in on the same port. This also applies to persistent locking and transaction bracketing. To make data more readily available to multiple clients, you can read data into a middle-tier so that you don't need to hit the server all the time. All clients can access that pool of data, or you can pull data into individual clients. Your .NET code would need to be written to generate the data (simply call the prog as above), pull it into these tiers, and then your client-side data access would need to be able to figure out where to go for data - client, middle-tier, or DBMS. This can actually be handled through some layer of abstraction so that the client doesn't really know where data comes from, the data is just "there". As a distributor for mv.NET I'll be happy to provide more details off-list and even set you up as a reseller. Our value-add offering includes all levels of .NET training, close product support, and assistance with development, sales, and marketing. HTH, Tony Gravagno Nebula Research and Development TG@ removethisNebula-RnD.com http://www.bluefinity.com/nebula.html Nick Cipollina wrote: > The reason that our current processes are so fast is that > we read as much common data as humanly possible into > memory at start-up so there is little overhead while the > process is running. If I have to call a subroutine from > .NET, that would actually slow processing down. I need > to get the data into .NET's memory to do something > similar. > > What about some of the other .NET options, such as > MV.NET? Any thoughts on those? > wrote: > solution that might provide us with similar performance? > I've seen some talk on this list of some of the other > solutions such as MV.NET, but I don't recall seeing any > metrics provided with any of these discussions. Any > feedback would be appreciated. Thanks. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
