After installation, I was able to successfully create a business object and map it to a table on my remote database.  A new form was created, the business object attached and some fields slapped on for testing.  No errors upon the build; however, if I run the debugger, the application fails nearly immediately with some such statement that my DataLayer is out of whack.  If I goof around with the program.cs file, I can get a database connection popup to occur when I start the app...it is looking for the "missing" connection information:  server name, authentication, database name.  If I provide all of that, then I get an unathentication error.  What am I doing wrong?  I am going through the tutorial, but any kind of hint would be helpful on this...thanks!

Bill

All of Greg's comments are very good.  I thought I might add a few things that we do with our medical application as well.

We actually use a single database and include the SFS tables in that same database.  This just makes distribution easier in the long-haul for us.  But splitting these up is totally viable as well.  It really comes down to what would suit your needs best.

On our medical application we got kindof fancy so that none of the client workstations would ever have to ask for a connection...it finds the server by itself.  When the server installation takes place we DO ask for a connection through the installer.  This only has to be done once and when an upgrade occurs in the next update, this information is remembered so that they do not have to enter it again.  We have a service that runs on the server that manages our licensing, amongst many other things, including handing out connections to the clients.  When a client workstation starts and the doesn't know the connection information or the connection fails, it sends out a UDP broadcast to the network which the server "hears" and in turn sends out a UDP broadcast back to the client with the information that directs it to the server.  Once it finds the server, it will authenticate and the server will send the connection information back to the workstation.  All of this without the end-user ever having to know or do anything.  It has really made a difference in support....this is no longer a support issue....now we are one to other problems   If the connection needs to change, then we go to the server, open up the connection dialog (we have a UI interface on the server), change the connection string, then restart the service (all automated).  This may be more involved than what you are looking to do...but it may give you another idea.