Hi Trent,



Now you are getting me worry , but in a good way , most of my installations are local networks with 5-15 workstations and this functionality is something I can start using right away , if there is a beta or if you can share main logic of a sample application we can integrate with current version of SF would be a good Christmas present

Edhy Rijo

I agree.  Actually, the next version of SF will be more sophisticated here.  We will provide the ability to have an application server and hand out the connections like I mentioned before, as well as a file based connection string handler like the Shared Settings File.  So we will make sure that this gets corrected.

No problem, I was hoping I had missed it but was fairly certain I hadnt. Thanks for the confirmation.

Might be nice to add in the future if it is inteneted to be able to replace the need for a local connections.dat file

Keith Chisarik

Keith, I lied.  The shared settings file only holds one data source at a time....however, you can create 3 and them read them in.  Yesterday I created a post showing how to circumvent the ConnectionStringWizard and just loading in the settings file.  You could create 3 shared settings files and then read them in and create your data sources like this:

http://forum.strataframe.net/FindPost31649.aspx

Thanks Ill take that into consideration. Let me rephrase, how do you create multiple named connections in the Shared Settings File Wizard

The workstation count is in the 100 ballpark, would you consider that "too many people hitting the shared settings file all at the same time" ?

I was thinking since they are just reading, that it wouldnt be a problem...

Keith Chisarik

Yes, it is possible.  A shared settings file is just like the connection string wizard in regards to support however many data source connections you will have.

However, depending on what you are trying to accomplish and your network and client workstation load, you may want to consider creating a server or service that runs on your server and sends out a UDP broadcast telling the clients what the connection information is.  This is what we do in our medical application.  Each instance of the application creates a unique GUID that the client knows about as part of the install.  Then when it starts up, if it doesn't know the IP and port of the server, it listens for the UDP broadcast and then syncs up with the server by getting the connection information from the server when the server tells it the IP and port.

This allows the client to be totally "dumb", but accommodates any size network.  If you have too many people hitting the shared settings file all at the same time, you may run into some file contention issues if you are not careful. 

Just food for thought.

My application uses multiple named datasources, it is possible to set each via the shared settings file. I could not get the Shared Settings File Wizard to add mutliple connections.

There are 3 VFP and one SQL, so they are of mixed type as well.

Thanks,

Keith

Keith Chisarik