I have a simple one BO, one form project on a Vista 64bit system. When I do an F5, the form runs and the Database Connection Wizard appears. I setup the connection and the form loads and throws an error when I attempt to fill the BO.

The error is:-

DataLayerException
  An error occurred while creating a new DataLayer for the business object.
DataLayerException
  The DataSourceKey [] is not defined.

Each time I do an F5 and run the project, the Database Connection Wizard always displays. From what I have read, it doesn't look like the wizard is saving the connection details as I believe it is supposed to only run the wizard once.

Have I missed something silly?

Thanks,

Aaron

If you are using the SF sample database, try changing the name of the onnectionManager.ApplicationKey in your AppMain.vb class so it will create a new connection record.

This is just a guess

Afraid I am using my own database.

Thanks anyway,

Aaron

I am willing to bet that these files cannot be created or properly accessed.  However, this may not be the issue in the sense that the StrataFrame connection and the samples use these same files, so if they work then it may be a matter of setup.

In the case that this is the latter issue, look in your AppMain.vb or progam.cs files and look in the SetDataSources method.  If you are going to let the connection Wizard manage your connections, then you will need to have the Applicationkey as well as define the RequiredDataSources.

So you might let me take a look at your SetDataSources method to see what you have there if you don't get it figured out.

Thanks.

I have just experienced the same problem. Running as administrator allowed me to continue development and testing, however, my concern is how this will effect deployment of our application.

I prefer to leave permissions as default but I don't want all our users having to have administrator privileges. So is this a case of easing permissions on "C:\ProgramData\MicroFour\ConnectionData" and is there a recommendation of what the permissions should be?

Peter

You don't have to ease permissions on the entire machine.  Technically there should be permissions on this folder anyway for anyone to create, update, and access a file.  So there were actually restrictions placed on this folder or hightened security added via group policies to prevent this access.  You only need to allow permissions to this one folder if you are going to use the Connection String Manager.  The other option would be for us to add a preference so that you can set this folder location (which is truth is not a bad idea) but these would be the only two options.

I've done some more digging, and noticed that "C:\ProgramData\MicroFour\ConnectionData" has, amongst others, permissions that allow Users on my PC "read and execute" as well as "special" permissions ("Create file / write data", "Create folders / append data", "Write attributes", and "Write extended attributes") both inherited. However "AppKeys.dat" and "Connections.dat" don't have the special permissions.

Then I tried deleting the files and seeing what happened when they were recreated. First I ran one of our programs as administrator, the files were created with no special permissions for users, and the program ran fine. Subsequently running another of our programs as me, I got the exception we've been seeing. Then I tried again deleting the files and running a program as me. The files were created with permissions the same for users as before (but I also got extra permissions as owner), and the program ran fine. Subsequently running another program also worked fine. I don't dare try running as another user that isn't administrator. I haven't consciously changed any permissions settings, and there is no group policy running within our network that I know about (and I'm allegedly our expert on group policy, i.e. I've read a few chapters of a book).

Moral of the story: I'm confused and think making the location of the files configurable is a good idea.

Peter

We can add an option for this folder location, but it probably won't be a quick fix.  I will add it to my list.  To be honest, over the past 3 years, this logic has changed very little and the folder pathing and locations hasn't changed at all.  This is the first time that the permissions have ever become an issue...I don't know if Vista has exaserbated the problem or what, but I guess we can allow this folder to be set so that way the permission issues become the problem of the developer/IT people versus having a static location to which this file is created.