Randem Systems Support Board

Thanks again for your very good advice.  Interestingly, a Public Variable is used for the computername in constructing the UNC Path in the network environment.
 
BTW, when I said it's my app I was not quite accurate.  It's really an inherited app that is now mine.  Oh well, enough for today.  I think I'll go to bed and dream about doing it right.
 
Thanks again.

Using just the file name in your open statement is a little dangerous. Another program could change the current directory and then your app would fail. One should always use a fully qualified path to their files. Assuming App.Path will work in most situations but you should allow for your app to work 100% of the time.
 
To dynamically change the connection string is no problem there. Instead of using App.Path you would simply use the Public Variable set at startup time that points to the data folder. That same variable would proceed each file name in your open statement also. Not too big of a change the big part would be testing to make sure you got all of them...

You are most likely hard coding the locations in the app if it would be a large change for this.
 
Actually, the major databases (of which there are four) are accessed via ADO Connection Strings that reference either App.Path in a standalone environment or a UNC Path to the host in a network environment.  There are several other files (Random and Sequential) that are accessed via Open statements with just the file names (App.Path assumed).

You are welcome. In future apps you should use a Public Variable that contains the location of your data files and set it at program startup. You are most likely hard coding the locations in the app if it would be a large change for this.

It's my app but I'm not inclined to undertake what would be a significant rewrite to handle what is a large number of data files, several of which are accessed and updated in several different areas of the code (i.e. procedures).
 
I'll accept the vulnerability of C:UsersAppName or, given the nature of our customer set (largely a single-user environment), I may require Run as Administrator and use C:Program FilesAppName like is done in XP.
 
Thanks for your assistance.

Is this app a third party app or is it your app that your are deploying that has the data in the same folder as the application?
 
If it is a third party app, install it in the C:UsersTheirApp folder and you will have no security problems except it will be vulnerable to viruses and deletion by any user.
 
If it is your app then change the path that you access your data (writable) from App.Path to Environ(AppData)AppName and also deploy your data files to the Environ(APPDATA)AppName and you will be able to be security compatible.

app that you cannot change that has data files that get installed into the app's installation folder (ex. C:program FilesTheirApp).
 
That's what I have.  Perhaps I'll figure all this out and be able to tell users where the files are.  It seems that Vista has created complexity for the sake of security (and done a bunch of other things that seem to be change for the sake of change).

Yes, you should look at InnoScript 8.0 Build 0 Beta. It handle all of those installation issues automatically.Look at the  Release History for more information.
 
What I stated does not contradict. It states that you should install the app in the Program Files folder and the Data in the APPDATA folder.
 
The only time you should install the app in the APPDATA folder is if it is a legacy app that you cannot change that has data files that get installed into the app's installation folder (ex. C:\program Files\TheirApp). Under a limited users account the data in that folder will not be allowed to be written to and therefore you should install those kinds of apps to the C:\Users folder.

Now you do have questions  
Actually I'm using a PDW Setup at this point.  I have an InnoScript for a XP install but haven't yet prepared one for Vista.  I'm using V7.3 Build 0.
 
I am using a Vista computer with the PDW Setup.  The Install Problems material on your site says for Vista to:
 
-- Not require supervisory privileges
-- Not install to \Program Files with data files
-- Install to C:\Users\Public or C:\Users\AppName
 
What you are now saying seems to contradict this.

Yes, Sorry about that... My Bad... Now on to your statement.
 
What version are you using? That should be the NEW default installation locations for InnoScript. You are using Vista correct? If you install to the C:Users folder you will lose the protection Vista delivers by not letting virus/trojan/worms write to the protected space in C:Program Files. The exe under the C:Users folder will be open for attack...

BTW: You did not answer my questions so that I may help...
 
My post was a new one - there were no related questions - ??  With respect to Vista, I just installed from a Guest account.  The .EXE was installed to Program FilesXXX but the database files were installed to UsersGuestAppData....
However, the app runs okay with this installation.
 
I'm going to change the installation path to C:UsersAppName to see if both the .EXE and the database files go there.

That is only because you have Admin privileges (Where normal users should not have). If you were in a limited users account that would not work.
 
BTW: You did not answer my questions so that I may help...

If you are installing on Vista using the Program Files folder you will get issues if you attempt to create any file inside the installation folder. This is a Vista installation security measure.
 
NOT TRUE in my experience.  Using the PDW I was able to install both the .EXE and database files in the Program FilesXXX folder.  The app runs well, including database updates.

Please download and re-install the latest re-lease (Version 7.3 Build 2 Dated 11/20/2007). I assure you it will solve your dependencies issues.
 
I just re-installed this version and all was ok creating a new project.
 
Please describe your issue... I will help you get your app installed correctly using InnoScript.
 
Where did you attempt to install InnoScript?
 
If you are installing on Vista using the Program Files folder you will get issues if you attempt to  create any file inside the installation folder. This is a Vista installation security measure

I'm sure this program must work for some... but I cannot get it to even create a new project or open one. I just installed your latest version and have tried re-installing it in the default installation location... still crashes when I try to create a new project. I thought maybe this program would solve some dependancy issues I've had with a vb project that won't install right... but looks like its going in the circular file.