I want to try to set the timeout on the connection to see if this helps. How do you do this in the program.cs file? I think I need to increase the timeout somewhere in the framework related to: SFSPreferencesBO.RetrieveSecurityPreferences(); This may be causing my problem above.

I also have SQL Express tools loaded on the client workstation. When I tried to connect to the SQL Express database, it times out. Then if I try immediately again it connects. I noticed the default connection timeout was 30 seconds on the SQL Manager Tools login. I changed this to 60 secons and it connected the first time with no time out. So from this I am assuming there is some setting at startup of the SF Frameout that needs to be changed to allow a greater amount of time before timeout.

 


 

It looks like you are getting a timeout while filling a BO, as it shows on your stack trace:

at visualOfficeNet.frmMain.tblUCompany_ParentFormLoading() in C:\visualOfficeNet\visualOfficeNet\frmMain.cs:line 525

If you would like to try to change the timeout prior to the filldatatable, you can use the CommandTimeout, increasing it or even telling it to wait forever:

        '-- Establish locals
        Dim loCommand As New SqlCommand()

        '-- Create the command
        loCommand.CommandText = "SELECT * FROM YourTable"

        '-- if you want to wait as long as it takes, set CommandTimeout to zero
        loCommand.CommandTimeout = 0

        '-- if you want to wait like 60 seconds, set CommandTimeout to 60
        loCommand.CommandTimeout = 60

        '-- Execute the command
        Me.FillDataTable(loCommand)

Well, the most obvious thing to me is that you are trying to make a call to a database through a BO before you have ever set the connection string.  I will scan through all of the code that you posted, but this is a red flag:

//-- ToDo:  Configure the security settings
                //--------------------------------------------
                //-- Retrieve the global preferences
                try
                {
                    SFSPreferencesBO.RetrieveSecurityPreferences();
                }
                catch
                {
                        if (ConnectionManager.ShowAvailableConnectionStrings())
                        {
                            // Set the connections
                            ConnectionManager.SetConnections();

                            SFSPreferencesBO.RetrieveSecurityPreferences();
                        }
                }

In this code, you are placing a try/catch around attempting to retrieve the security preferences.  If you don't have your connection string set by this point, a try catch in this scenario isn't going to help and you are just going to make the end-user wait for a while as it times out.

I think that you are making this diagnosis far harder than it needs to be.  Go back to your program.cs and open the SetDataSources method.  Instead of calling SetConnections, manually specify the connection string just as you try and diagnose what is going on here.  This way you are not relying on the ConnectionStringWizard, but have hard coded the connection string.

MicroFour.StrataFrame.Data.DataBasics.DataSources.Add(new SqlDataSourceItem(string.Empty,"MyHardCodedConnectionString"));

If you aren't familiar with connection strings, here is a sample that specifies the password:

MicroFour.StrataFrame.Data.DataBasics.DataSources.Add(new SqlDataSourceItem(string.Empty,"server=MySqlServer;user=sa;password=MyPass;database=MyDatabase;"))

Here is a connection string that uses Windows authentication:

MicroFour.StrataFrame.Data.DataBasics.DataSources.Add(new SqlDataSourceItem(string.Empty,"server=MySqlServer;integrated security=SSPI;database=MyDatabase;"))

After you do this and get it working, then clear our the connections.dat again.  Then put back in the code that has the SetConnections();.  After this, if you still are not working, then turn on the debugging on the connection.  This will output an HTML file giving you all of the queries taking place and this will 100% clue you in.

MicroFour.StrataFrame.Data.DataBasics.DataSources[string.Empty].SetDebugOn(@"c:\output.html", true, true);

In the above code snippet, I like adding that last "true" as it will show a message reminding you that you have debug mode on.  It really stinks when you leave this on in a run-time environment by accident.

And finally, as you have learned the hard way, I never recommend installing a trial version of anything in a production environment because it seems to expire and have issues causing down-time.  I too have learned this the hard way.

I did as you suggested:

Go back to your program.cs and open the SetDataSources method. Instead of calling SetConnections, manually specify the connection string just as you try and diagnose what is going on here. This way you are not relying on the ConnectionStringWizard, but have hard coded the connection string.

This still timed out as it did before and brought up the ShowConnections. Then I added Connect Timeout=100 to the connection string and then it did not timeout and the ShowConnections did not appear and the log in dialog to the app appeared as needed. The default for timeout on SQL Express is 30 which isn't always enough.

When I looked at the debug file to see what happens first shows:

Command #:  1 
Timestamp:  2012-02-08 13:27:55.427 
General Command Settings 
Command Type:  Text 
Object Type:  System.Data.SqlClient.SqlCommand 
Connection String:  server=RROOKER-HP;integrated security=SSPI;database=Auxiliary; 
Transaction:  False 
Command Settings 
CommandText:  SELECT * FROM [dbo].[SFSPreferences] 
Command Parameters 
N/A  No parameters are defined 

Then I deleted the 2 Connection files under All Users and tried as you suggested and since at that point there is no way to add a connection timeout in the Connection Wizard, it defaults back to 30 and I have the same problem. So for now I think I am stuck with overriding the connection.