Reading from a database located in the Program Files folder using ODBC

We have an application that stores its database files in a subfolder of the Program Files directory. These files are redirected to the VirtualStore in Vista and Windows 7. We represent data from the database using Microsoft DataReports (VB6). So far so good.

But we now want to use Crystal Reports XI to represent data开发者_如何转开发 from the database. Our idea is to NOT pass this data to CR from our program, but to have CR retreive it from the database using a a system DSN through ODBC. In this way we hope to present our users with more flexibility in designing their own reports. What we do want to ensure though is that these system DSNs are configured correctly when the user installs our program or when the program calls the Crystal Report.

Is there a smart way to do this using System variables for instance, instead of having to write a routine that checks for OS-version, whether UAC is enabled on the OS, whether the write restrictions on the Program Files folder have been lifted, etc and then adapts he System DSN to point to either the C:\Program Files\OurApp\Data folder, or the C:\Users\User\AppData\VirtualStore\Program Files\OurApp\Data folder?

Suggestions for an entirely different approach are welcome too!

New applications should have an application manifest that specifies requestedExecutionLevel. This declares your program "Vista aware" and bypasses attempts at virtualization.

During installation you should create a folder like [CommonAppData]\Company\App\Full and set security on this folder to allow Full Access by Everyone (or by Users). Put your database into this folder.

For an MDB you can drop the database right here. For a client/server database put a UDL file here. Also see Use Universal Data Link (.udl) Files.

ODBC and DSNs are pretty obsolete technologies.

Using the suggested approaches should work for almost anything but the oldest Win95 computer.

Is this an Access database? You haven't specified.

For an Access database, you don't need to point your DSN to a specific database when you install it. You can modify the connection string to point to different databases at runtime (details). For instance

Driver={Microsoft Access Driver (*.mdb)};Dbq=C:\mydatabase.mdb;Uid=Admin;Pwd=;

Can you simply read the installation path at runtime (in VB6 it is App.Path) and then send a different connection string to Crystal Reports?

It seems that Virtual Store takes care of everything, so you can point the DSN blatantly at C:\Program Files\MyApp\Data\mydb.mdb even while the database has been relocated to the Virtual Store.

Current Version

You might want to detect the current-version of Windows the system is running.

This will in turn help You in determining the correct PATH.

How to find windows version, build and revision numbers??

Read the the Registry keys –

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentBuildNumber  
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\CurrentVersion
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\EditionID  
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProductId 
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\BuildLabEx

The CurrentBuildNumber is your Windows Build Number. Then CurrentVersion value is your windows version i.e. the version of your windows 7, windows vista, windows xp, etc. EditionID and ProductId to know the windows-edition and product-id.

The key BuildLabEx contains build number and revision number.

For example, in the value 6001.17387.x86fre.vistasp1_gdr.070927-1921:

• the first four digits stand for build number i.e. 6001 and

• the next five digits stand for windows revision number i.e. 17387.

• x86 tells you that you are running a 32-bit operating system.

You might also be interested in this:
How to detect true Windows version?

GoodLUCK!!