It makes no difference if I enter the connection information manually or use a shared settings file. The only thing that matters is that a connection is added or edited in the Connection Wizard and that the project is a SF Windows application with security. In every test I've run if the Connection Wizard is used to add or edit a connection and the application uses SF security, I'll get an application exception when I exit the application.

-Larry 

Do you get the same error if you do not use a Shared Settings file?

Just in case I didn’t make it clear in my previous posts, when the Connection Wizard is run within an application, you have to either add a new connection or edit the existing one for the exception to occur. Simply selecting another connection from the list of available connections will not produce an exception.

-Larry

Hi Ben,

Here is a little more info. I enabled unmanaged code debugging on my VB test app and the following showed up. It corresponds to the exception I'm getting.

The thread 'Win32 Thread' (0x494) has exited with code 0 (0x0).

First-chance exception at 0x7c812a5b in SF1TestVB.exe: 0xC0020001: The string binding is invalid.

-Larry

It seems to be coming form some sort of unmanaged call that isn't being cleaned up or disposed, or something... I'll take a look at it.  Thanks for the additional info.

Trent,

I do all my development in VB but I thought I run a test in C# and see if the results were any different. My test application is nothing more than a SF Windows app with security and one form, a SF Main form. I’ve added no code to what is generated from the templates. I ran the app, manually entered the connection data in Connection Wizard and clicked on exit when the authorization form was displayed. Attached in a screen shot of the error I received.

-Larry

I’ve tried using the shared settings file and I’ve tried entering the information manually. I’ve also tried copying the shared settings file to a local drive. In all cases I get an application exception when I exit the program. You’re correct that if I just hard code the connection string in AppMain everything works fine. Running the Connection Wizard appears to be the cause of the problem when run in an application that uses SF Security. If I create SF Windows app without security, I can run the Connection Wizard as many times as I want and it doesn’t cause an application exception when exiting the application.

 

In my application I’m using SF Security only for password validation. The only restriction we have for our tracking app is that the user is an authenticated user. I haven’t defined any roles or permissions. My Test application contains just one user with no roles or permissions. This doesn’t cause any problems with the app; everything works fine except when the Connection Wizard is run. I did try creating a role and permission for the one user but that didn’t seem to change anything. I’m wondering if I’m missing something when setting up a project with security. It’s driving me nuts that you can’t reproduce this problem when I can 100% of the time on four different development machines running two different operating systems.

 

-Larry

 

All of this looks good.  Here is one question though, you mentioned you are using a shared settings file...does the same thing happen if you just manually enter the information in the Connection Wizard and do not use the shared settings file?  This could be the culprit as it does some stuff in memory and if it is coming from a network drive, I see this being a potential cause of the error since you are getting an exception.

Also, I am assuming that if you manually set the DataSources collection and circumvent the Connection Wizard, you do not get the error...correct?  Try taking the shared settings file out of the formula first, then we will go to hard-coding the path.  Let's get the error to go away and then we can start adding things back in.  Thanks.

Trent,

 

I’ve done quite a bit of testing and in all cases I’ve been able to consistently reproduce the application exception I’ve been getting. It is important to note that the exception ONLY occurs on a SF Windows Application with Security. A standard SF Windows Application does not exhibit the problem.

 

The exception only happens on exiting the application if the Database Connection Wizard has been run in the current instance, either on startup where the applications data base has not yet been defined or if run from the File menu on a SF Main form. If run from the File menu you must run the wizard all the way through the Finish step for the exception to occur on exiting the application.

 

So far I haven’t been able to isolate the cause of this problem. It’s happening on every PC where I try to deploy an app as well as two development PCs that I’ve tested. To eliminate as many variables as possible, I’ve also done the following, once under Windows XP Pro SP2 and once using Windows 2000 Pro SP4. In both cases I received an exception (although at different locations depending on the OS). I could be missing something when I’m setting up the environment and building the test app, but I can’t see what it is. Maybe you can.

 

·     Started with a Dell GX280 and reformatted the drive.

·     Installed Windows XP Professional SP2 with no additional updates

·     No anti-virus software installed on PC

·     Installed VS2005 Professional, default install from Dec 2005 Microsoft volume licensing discs. No additional updates or patches installed.

·     Installed SQL Server 2005 STD using Dec 2005 Microsoft volume licensing, all services installed. No additional patches or updates installed.

·     Rebooted PC

·     Installed SF v1.5 11/09/06 without DevExpress or Infragistics with StrataFrame DB on local SQL instance

·     Created a Security project and added 1 user (used “MySecurityKey” for key)

·     Ran DDT to create a database that includes 1 table + Security tables, no localization or message tables

·     Deployed the new DB to the local SQL instance with the data from the Security project

·     Created a new StrataFrame Windows project with security. No modifications to AppMain

·     Replaced the standard form with a SF main form.  Left name as Form1 with no code added

·     No business objects were added to the project

·     Ran program in designer

·     In the connection wizard configured the app to use the new data base with Windows security.

·     When the Authorization form is displayed, clicked on Exit

·     Program throws an application exception (same as previous posts)

·     Clicked on Stop Debugging.

·     Re-Ran application

·     When the Authorization form is displayed, clicked on Exit

·     Application exited with no exception

·     Re-Ran application

·     Entered ID and password on Authorization form,  clicked OK

·     Main form is displayed

·     Clicked on File, Database Connection menu

·     Selected the current connection

·     Clicked on Edit

·     Ran through the Connection Wizard, leaving the information the same

·     Clicked Cancel on the connection windows to close

·     Closed the Main form to exit application

·     Application exception raised

 

 

All the PCs where I’ve tested running the VS2005 design environment are Dell GX280 or GX620 systems. Deployed systems have been GX620s as well as no-name clones running either Windows XP SP2 or Windows 2000 Pro SP4.

 

After running the initial test of the bare bones XP machine, I applied all of the latest XP patches and SQL 2005 SP1.  The results were still the same.  As far as I’m aware there are no SPs for VS2005. I’ve tried using local databases and remote databases. I’ve even taken the development systems off the network. The results are always the same.

 

Any suggestions would be appreciated since the current situation is making deployment of SF applications very difficult (I’m using a shared configuration file). I haven’t tried it yet but I’m assuming that I could work around the issue by hard coding the connection string in AppMain.

 

-Larry

 

 

Larry,

I know that you do not want to hear this, but I have tested this on two different computers, and spent a fair amount of time on this including last night at home, and I cannot reproduce this.  There is something in your application, development, and/or run-time environment that is not playing nice with your assembly.

You know us, we like to fix things , but we have to be able to reproduce them before we can.  Obviously this is an isolated type of thing in your environment otherwise we would be hearing about this from every one of our users....not that it makes you feel any better  

Have you loaded any type of patch to VS 2005, the OS, or something that could be playing a part here?