Hello:

For anyone doing c/s installations, where are you putting the database
files?  And why there?

Regards,

Dale

Dale,

I usually let the user chose the location when he first installs the server.
My setup program (built with InnoSetup), wich installs the EDB Server, asks
the user where does he want to create the Database, and also the Stores if
needed, and suggests the default location recommended by Microsoft that is
the CSIDL_COMMON_APPDATA special folder.
--
Fernando Dias
[Team Elevate]

Hi Dale/Fernando,

For what it's worth, we've encoutered problems using CSIDL_COMMON_APPDATA on
Vista machines due to Virtualization.

In WinXP, commonappdata = C:\Documents and Settings\All Users\Application
Data
in Vista, commonappdata = C:\ProgramData

Vista's Virtualization is a complete nightmare as virtualized folders
*appear* to allow non-admin users to read/write to the folder, but in actual
fact the OS is redirecting any new/updated files to a different folder only
accessible to that user.

This post explains more :-
http://www.eggheadcafe.com/software/aspnet/29106649/file-locations-to-avoid-v.aspx

To avoid the problem, our installer now simply asks the administrator who is
installing the software to select a "data folder" (by default
"C:\OurApp.data") and notifies them that they will need to grant full access
to that folder for all non-admin users.

It's not ideal, but it works with both WinXP and Vista.

Hope this helps.

Some more info :-
http://www.symantec.com/community/article/2665/folder-virtualization-concepts-windows-vista
http://mutable.net/blog/archive/2008/03/31/vistas-virtualized-folders.aspx
http://www.west-wind.com/Weblog/posts/5584.aspx

Hello:

> In WinXP, commonappdata = C:\Documents and Settings\All
> Users\Application Data

Common_App_Data sounds like the correct place to put it (per Microsoft),
but many of our customers are very low-tech, and it becomes a real tech
support headache for instance, when they want to move their database to
another computer and they can't find it.  (I wish everyone had their own
 IT Administrator on staff, but alas, they don't)


> Vista's Virtualization is a complete nightmare.....

This is a HUGE problem! I wish I could send Microsoft a bill for the all
the extra work this has caused, both for us and our customers.



> To avoid the problem, our installer now simply asks the administrator
> who is installing the software to select a "data folder" (by default
> "C:\OurApp.data") and notifies them that they will need to grant full
> access to that folder for all non-admin users.


I'm leaning toward something similar to the above.  Our app will be
installed in Program Files, but during the install, I'll have the user
specify the data location, with the default something like "C:\<our data
folder>"


Fernando & Hedley, thanks for the replies.

Anyone else?

Dale

Dale,

we put all our programs in directory named 'c:\kres' (our company's name is
KreS) on local machines or on server. Our installer (Inno setup) makes a
common subdirectory 'EDB' in which we put all files, used by ElevateDB, that
is EDBConfig.cfg, edbmgr.exe, edbsrvr.exe, edbsrvr.ini and
edbmigratedbisam4.dll for migration purposes. Then for each of our programs
installer makes subdirectory with the same name as the our program name is.
In this directory we put the program. Data folder is inside this folder and
we put in it EDBDatabase.cat and other EDB files

The complete directory structure then looks like:

c:\kres
       \EDB                for edbconfig.cfg, edbsrvr.exe and edbsrvr.ini
       \panorama        for program 'panorama.exe'
               \data        for data used by program 'panorama'
       \intra                for program 'intra.exe'
               \data        for data used by program 'intra'
       \ : : : : :

We never had problems with OS access restrictions because we strictly avoid
directories Program Files and other directories used by OS.

HTH
Iztok Lajovic


<user@domain.invalid> je napisal v sporocilo
news:6EAB0D1A-1EA3-406F-9783-7565B63C96D0@news.elevatesoft.com ...
> Hello:
>
>> In WinXP, commonappdata = C:\Documents and Settings\All Users\Application
>> Data
>
> Common_App_Data sounds like the correct place to put it (per Microsoft),
> but many of our customers are very low-tech, and it becomes a real tech
> support headache for instance, when they want to move their database to
> another computer and they can't find it.  (I wish everyone had their own
> IT Administrator on staff, but alas, they don't)
>
>
>> Vista's Virtualization is a complete nightmare.....
>
> This is a HUGE problem! I wish I could send Microsoft a bill for the all
> the extra work this has caused, both for us and our customers.
>
>
>
>> To avoid the problem, our installer now simply asks the administrator who
>> is installing the software to select a "data folder" (by default
>> "C:\OurApp.data") and notifies them that they will need to grant full
>> access to that folder for all non-admin users.
>
>
> I'm leaning toward something similar to the above.  Our app will be
> installed in Program Files, but during the install, I'll have the user
> specify the data location, with the default something like "C:\<our data
> folder>"
>
>
> Fernando & Hedley, thanks for the replies.
>
> Anyone else?
>
> Dale
>
>
>
>
>

Hedley,

<< For what it's worth, we've encoutered problems using
CSIDL_COMMON_APPDATA on Vista machines due to Virtualization.
In WinXP, commonappdata = C:\Documents and Settings\All
Users\Application Data
in Vista, commonappdata = C:\ProgramData>>

Virtualization can be a problem, but not here, I think.
You can have virtualization problems if you hard-code the paths - then
Vista will map them to whatever it thinks is correct, but if you get the
locations by querying the OS using CSIDL_COMMON_APPDATA identifier at
runtime you will get the correct path in both operating systems.

<< To avoid the problem, our installer now simply asks the administrator
who is installing the software to select a "data folder"  >>

I think this is the best option. However, I'm planning on changing my
setup script for servers as soon as I have time to do it, since
suggesting a path in drive c: as a default location doesn't make much
sense for "real" servers.

--
Fernando Dias
[Team Elevate]

Dale

> I'm leaning toward something similar to the above.  Our app will be
> installed in Program Files, but during the install, I'll have the user
> specify the data location, with the default something like "C:\<our data
> folder>"

Are you going to install the application in the server too? Because if
you don't then you must remember that when you use C/S database paths
are relative to the server.

--
Fernando Dias
[Team Elevate]

Fernando Dias wrote:
> Dale
>
>> I'm leaning toward something similar to the above.  Our app will be
>> installed in Program Files, but during the install, I'll have the user
>> specify the data location, with the default something like "C:\<our
>> data folder>"
>
> Are you going to install the application in the server too? Because if
> you don't then you must remember that when you use C/S database paths
> are relative to the server.
>


Fernando:

Only the server would be installed on the server machine, unless the
user really wanted to run the main app there also.  In that case, the
main app would be configured to access the localhost and not a hard
coded path.

Dale

Fernando Dias wrote:
> Hedley,
>
> << For what it's worth, we've encoutered problems using
> CSIDL_COMMON_APPDATA on Vista machines due to Virtualization.
> In WinXP, commonappdata = C:\Documents and Settings\All
> Users\Application Data
> in Vista, commonappdata = C:\ProgramData>>
>
> Virtualization can be a problem, but not here, I think.
> You can have virtualization problems if you hard-code the paths - then
> Vista will map them to whatever it thinks is correct, but if you get the
> locations by querying the OS using CSIDL_COMMON_APPDATA identifier at
> runtime you will get the correct path in both operating systems.
>
> << To avoid the problem, our installer now simply asks the administrator
> who is installing the software to select a "data folder"  >>
>
> I think this is the best option. However, I'm planning on changing my
> setup script for servers as soon as I have time to do it, since
> suggesting a path in drive c: as a default location doesn't make much
> sense for "real" servers.
>

Fernando:

This sounds like the preferred method to me as well.... unfortunately, I
have users who can't even find Program Files, let alone C:\Documents and
 Settings\All Users\Application Data.  And on top of that, isn't this
folder normally hidden?  That adds yet one more layer of instruction to
pass along to the users.

I'm worried that we will spend loads of time on the phone providing tech
support to our users when they decide to move the database to a new hard
drive or computer.

On the other hand, if you look at it from a security standpoint, along
with compliance/compatibility with future versions of Windows, then
COMMON_APPDATA seems to be the way to go.

Have you experienced any issues with your customers using COMMON_APPDATA?

Dale

Dale,

> This sounds like the preferred method to me as well.... unfortunately, I
> have users who can't even find Program Files, let alone C:\Documents and
>  Settings\All Users\Application Data.  And on top of that, isn't this
> folder normally hidden?  

Yes, this directory is normally hidden.
OSs may behave differently, but not users, no matter the country,
language, etc.

> Have you experienced any issues with your customers using COMMON_APPDATA?
No, except for the fact that they normally can't find where the
directory is located. However, as I said I'm planning on changing this
in future releases.
What I intend to do is to store configuration files like my own "INI"
files and application logs in COMMON_APPDATA and the Databases and
Stores in the directories the users chose when they install EDB Server.
There is only one detail that is not clear to me yet that is the best
location to the EDBConfig file. At the moment I'm using COMMON_APPDATA.

--
Fernando Dias
[Team Elevate]