persistently storing a DB path

[Datadis]

Hi,

is it possible to store user input information in the registry (or reading/creating registry keys in general) from a vfp application?

The application I'm working on will be shared by a few users in an environment with no server, so I thought the only solution would be to store the DB on a shared folder... and store the relative path to that folder in each of the users' registry after succesfully opening it (the DB) for the first time. Does it make sense? And, more importantly, is it possible?

As always, suggestions will be appreciated!

thanx!

Pascal Marier-Dionne

 

[alvechurchdata]

is it possible to store user input information in the registry (or reading/creating registry keys in general) from a vfp application?

Yes. There's a Registry Access Foundation Class and examples of code in the Sample application. Details in VFP Help.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[jesylv]

You could also store that information in a txt file making it easier to port the data to a different folder. See filetostr() and strtofile() functions. Other important point: I would use UNC notation (\\SERVER\SHAREDPATHNAME\) since the mapping could be different from one installation to another.



Jean

 

[alvechurchdata]

You could also store that information in a txt file making it easier to port the data to a different folder.

That's what I do. We still use the Win 3.11 style of Ini file because some of our clients really don't want us meddling with the Registry. Something like this:

;Any line starting with a semi-colon will be ignored
;DATAPATH=\\Toshibapro\tosh_pro\TestData
DATAPATH=..\Data

The other advantage is that it's easier to support changes on site. It's easy to talk a user through the process of editting an Ini file with NotePad or I can just email them a new file. I wouldn't like to talk a naive user through the use of RegEdit.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[JRB-Bldr]

While there are many good points explained above for using a Text file, another way would be to have your application create a Local DBF table (usually in a directory also created by the VFP application) and save the input information in there.

Then when needed, the VFP application can easily access it and save it into a PUBLIC variable for use throughout the application.

I have used that method a number of times and it has worked well for my users.

When a user needs to change the settings, the user can merely delete the DBF table and the VFP application, recognizing its absence and/or lack of data in the table, will again ask the user for input.

Good Luck,
JRB-Bldr

 

[jesylv]

Yes you could use dbf but being able to edit the paths in notepad is cool specialy if there is no security issues. Furthermore, you could use jrbbldr's suggestion: If the txt or ini file is absent, you call a dialog to capture proper path (getdir()) and then recreate the file...

Jean

 

[alvechurchdata]

I'm with Jean. I used to use a dbf in 2.6 because it was so much easier than the low-level routines needed to write a text file. I was glad when FILETOSTR and STREXTRACT let me use a plain ini file.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[rkolva]

I would say it depends on the situation if you use a dbf or ini/txt file. For settings that aren't security issues or need to be potentially edited by the user I use the Config.fpw as an ini file. For settings that are a little more sensitive I use a table and for things that are really sensitive like passwords I'll use and encrypted table. The problem with increasing security is that it also makes maintenance more difficult.

For reading ini settings from an ini/fpw file I treat it the same as any ini file and use the following function around an API call. It saves me the trouble of building a function that scans the text file for the value I need.

FUNCTION ReadIni
LPARAMETERS vcSection, vcEntry, vcINIFile	
	LOCAL lcDefault AS Character , lcRetVal AS Character, lnRetLen AS Number
	
	lcDefault = ""
	lcRetVal  = space(255)
	lnRetLen  = LEN(lcRetVal)
	
	DECLARE integer GetPrivateProfileString IN WIN32API ;
        STRING vcSection, ;
        String vcEntry, ;
        STRING lcDefault, ;
        STRING @lcRetVal, ;
        INTEGER lnRetLen, ;
        STRING vcINIFile
	                
	nRetLen = GetPrivateProfileString(vcSection,;
    	vcEntry, ;
        lcDefault, ;
        @lcRetVal, ;
        lnRetLen, ;
        vcINIFile)
        
	RETURN LEFT(lcRetVal, lnRetLen )
ENDFUNC

A typical call would be the following:

lcPath = ReadIni("APP SETTINGS", "Data_Path", "CONFIG.FPW")

Just be careful of the NULL terminater at the end of the string that's returned.

Come to think of it I may have gotten part of the code, at least the idea, from a post in this forum. I apologize for not having attributed the idea/code to the author. If this original idea was yours please take credit and I'll not my function appropriately.

Ralph

 

[alvechurchdata]

The problem with increasing security is that it also makes maintenance more difficult.

Especially when you (as the developer) aren't on site. I try to steer our clients away from excessive security to avoid these problems. There's no point having military-grade security on the Customer Address file if the same information is being printed out and left for the cleaners to read every night.

Geoff Franklin

http://www.alvechurchdata.co.uk