Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Enhancement Requests and Suggestions » View Thread |
Messages 1 to 8 of 8 total |
ElevateDB - Playing well with Vista |
Fri, Apr 20 2007 10:25 PM | Permanent Link |
"Lance R" | Tim,
There's a sort of chicken / egg thing with permissions that would be nice to address. Please read in the irony and distain in my "voice", but its something to consider. "Uncle Bill" says apps should go into Program Files. And... By the way... Anything in Program Files is Read Only...... Not a problem. I'll put the ElevateDB server in program files because its just an app. "Uncle Bill" says data should go into the User's sub folders (or Documents and Settings\ for XP). This is read/write. Not a problem. I'll put the ElevateDB data in C:\Documents and Settings\All Users\Application Data\ElevateDBData so that server only deals with ONE set of data and can serve no matter which user logs in. And since I still need to deal with a temp folder, I'll nest the temp folder inside of this to take care of that. So far so good. Now, I need to change the INI for the server to point to these places. The settings in the INI are not a problem. Those can be changed to "uncle Bill's" scheme with what I set up and all is "almost" well with the world. Here's the problem. The Server needs the ini in its folder to... well... get its settings. But if you stop the server, you can edit these settings and.... wooops. The INI is in a read only folder. Soooooooo. Here's a suggestion that may sound dumb, but its the only thing I can think of. Use an INI file in with the app that POINTS to the ini will all the server settings. This way the ServerSettings.INI file can be in the R/W place and the Pointer INI file would typically never get changed. During install, if we are choosing a PER user, then we would set the pointer INI to the XXX user's Application Data\.xxxx folder. If we want Machine, then we put in All Users. Anyways.. Food for thought. Lance |
Sat, Apr 21 2007 9:09 PM | Permanent Link |
Dave Harrison | Lance R wrote:
> Tim, > > There's a sort of chicken / egg thing with permissions that would be nice to > address. > > Please read in the irony and distain in my "voice", but its something to > consider. > > "Uncle Bill" says apps should go into Program Files. And... By the way... > Anything in Program Files is Read Only...... Not a problem. I'll put the > ElevateDB server in program files because its just an app. > > "Uncle Bill" says data should go into the User's sub folders (or Documents > and Settings\ for XP). This is read/write. Not a problem. I'll put the > ElevateDB data in C:\Documents and Settings\All Users\Application > Data\ElevateDBData so that server only deals with ONE set of data and can > serve no matter which user logs in. And since I still need to deal with a > temp folder, I'll nest the temp folder inside of this to take care of that. > > So far so good. > > Now, I need to change the INI for the server to point to these places. The > settings in the INI are not a problem. Those can be changed to "uncle > Bill's" scheme with what I set up and all is "almost" well with the world. > > Here's the problem. > > The Server needs the ini in its folder to... well... get its settings. > > But if you stop the server, you can edit these settings and.... wooops. > The INI is in a read only folder. > > Soooooooo. > > Here's a suggestion that may sound dumb, but its the only thing I can think > of. > > Use an INI file in with the app that POINTS to the ini will all the server > settings. This way the ServerSettings.INI file can be in the R/W place and > the Pointer INI file would typically never get changed. During install, if > we are choosing a PER user, then we would set the pointer INI to the XXX > user's Application Data\.xxxx folder. If we want Machine, then we put in > All Users. > > Anyways.. Food for thought. > > Lance > Lance, So how do you change the path in the INI file (which is read only) that points to the other ini file? Seems like a PIA to me. Why not just set a registry entry that points to the main .ini file? Dave |
Sat, Apr 21 2007 9:39 PM | Permanent Link |
Lance Rasmussen Jazzie Software Team Elevate | An installer could create the pointer INI file on the fly. Appropriate
permissions would be needed to install the program anyways. Registry would be fine too... You just have to be careful with that. Vista can sometimes virtualize a registry entry. Writing the registry to HKCU isn't a problem. In theory, it should be fine if you set HKLM if you are running the server for EVERYONE providing the installer's privileges elevates to admin. Lance > Lance, > So how do you change the path in the INI file (which is read only) > that points to the other ini file? Seems like a PIA to me. Why not just > set a registry entry that points to the main .ini file? > > Dave |
Sat, Apr 21 2007 10:58 PM | Permanent Link |
"Royke" | But wouldn't it be a bit inconsistent to put the data in 'All users' and
then the ini-file location in HKCU? RJ "Lance Rasmussen" <lance at lance.ws> wrote in message news:911BCB83-E05A-4F7A-962F-C8D8A976A1DC@news.elevatesoft.com... > An installer could create the pointer INI file on the fly. Appropriate > permissions > would be needed to install the program anyways. > > Registry would be fine too... You just have to be careful with that. > Vista > can sometimes virtualize a registry entry. > > Writing the registry to HKCU isn't a problem. In theory, it should be > fine > if you set HKLM if you are running the server for EVERYONE providing > the installer's privileges elevates to admin. > > Lance > > >> Lance, >> So how do you change the path in the INI file (which is read only) >> that points to the other ini file? Seems like a PIA to me. Why not just >> set a registry entry that points to the main .ini file? >> >> Dave > |
Mon, Apr 23 2007 1:11 PM | Permanent Link |
"Lance R" | RJ,
yep.. It may have got lost in translation, but you would be correct. If installing the server at the machine level, you would put the data in "All Users" and the INI in HKLM. If installing the server at the user level, you would put the data in "USERXXX" and the INI in HKCU. Lance "Royke" <royke@canada.com> wrote in message news:0BFFE92E-1D26-41A8-98FC-5AAC66B46096@news.elevatesoft.com... > But wouldn't it be a bit inconsistent to put the data in 'All users' and > then the ini-file location in HKCU? > > RJ |
Mon, Apr 23 2007 4:14 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Lance,
<< Here's a suggestion that may sound dumb, but its the only thing I can think of. >> I think I might rather go with a setup that simply stores the server's .INI in the common application data folder for all users. I'll have to think about this some more, but that's my initial thoughts. -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Apr 24 2007 12:04 PM | Permanent Link |
Lance Rasmussen Jazzie Software Team Elevate | I tend to agree Tim,
The only thought would be if you want the flexibility of installing different instances of the server for different user accounts. Personally, I don't see the need to install the server for anything other than ALL Users, but thats my humble opinion. The main thing I wanted to point out was the permissionary issues that are there with a locked down XP / 2K system, but especially our "favorite" new MS OS. Lance "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:2B6E5DCC-1389-41E6-B3CD-391EC2C55C9C@news.elevatesoft.com... > Lance, > > << Here's a suggestion that may sound dumb, but its the only thing I can > think of. >> > > I think I might rather go with a setup that simply stores the server's > .INI in the common application data folder for all users. I'll have to > think about this some more, but that's my initial thoughts. > > -- > Tim Young > Elevate Software > www.elevatesoft.com > |
Wed, Apr 25 2007 8:19 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Lance,
<< The only thought would be if you want the flexibility of installing different instances of the server for different user accounts. Personally, I don't see the need to install the server for anything other than ALL Users, but thats my humble opinion. >> Yes, and there's the issue of running it as an application, and then trying to run it as a service, or vice-versa. Obviously, it would be best if the configuration was in a common folder for all users. << The main thing I wanted to point out was the permissionary issues that are there with a locked down XP / 2K system, but especially our "favorite" new MS OS. >> Yes, and I appreciate it very much. I fixed the EDB Manager, but the server was a bit of an oversight. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Friday, April 19, 2024 at 07:09 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |