Trent Taylor
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
You can install a build that allows you to add this functionality here: http://forum.strataframe.net/FindPost15687.aspxYou will want to set the ConnectionManager.ConnectionDataFolder property for your application prior to calling the SetConnections() method. We will probably allow this to be set for the StrataFrame environment itself in the next update. But for now you can at least get your applications finalized with this functionality.
|
|
|
Edhy Rijo
|
|
Group: StrataFrame Users
Posts: 2.4K,
Visits: 23K
|
Trent L. Taylor (04/15/2008) ...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.Hi Trent, Well Vista security like the previous MS-OS will always cause many issues like this one, so I vote for an option to allow us to select the location where these files will be store.
Edhy Rijo
|
|
|
Trent Taylor
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Permission issues are something that we have fought from the inception of Windows. We have some shops who don't even allow temp files to be created...it is a constant fight between applications and network people trying to make things work. 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.
|
|
|
Peter Denton
|
|
Group: Forum Members
Posts: 77,
Visits: 787
|
Trent, 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
|
|
|
Trent Taylor
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
So is this a case of easing permissions on "C:\ProgramData\MicroFour\ConnectionData" and is there a recommendation of what the permissions should be? 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.
|
|
|
Peter Denton
|
|
Group: Forum Members
Posts: 77,
Visits: 787
|
G'day 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
|
|
|
Trent Taylor
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Cool. Glad it worked.
|
|
|
Aaron Young
|
|
Group: StrataFrame Users
Posts: 277,
Visits: 1.1K
|
You are right - it is a permission problem. Running VS2008 as Administrator and the connection saves and the form works. Running again with normal permissions and the form continues to operate. Thanks.
|
|
|
Trent Taylor
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
Actually it is probably a permissions issue. We create two encrypted files in the All Users App data folder. One called Connections.dat and another caled AppKeys.dat. 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.
|
|
|
Aaron Young
|
|
Group: StrataFrame Users
Posts: 277,
Visits: 1.1K
|
Hi Edhy, Afraid I am using my own database. Thanks anyway, Aaron
|
|
|