Clipper File Security On WIN NT

Clipper File Security On WIN NT

Author

Message

Ray Puhalsk#1 / 5

Clipper File Security On WIN NT

I have an application that runs on customer sites. The app is programmed in v5.2, uses CA Tools, linked via Blinker v3.1. A user has all rights to the directory where this app resides on their server; required by application. Yesterday, a user used MS Excel to link a spreadsheet to the app files; changed the structure of the files they had linked; destroyed the files.

I would like to be able to password protect the files and/or the directory and only give this password to the app program which would be the only EXE to have access to these files.

Does anyone have any ideas or suggestions ?

It would be nice to be able to somehow lock out all of those tools that exist at a customer's site.......a little knowledge has now become a deadly thing.

--== Sent via Deja.com http://www.*-*-*.com/ ---Share what you know. Learn what you don't.---

>I have an application that runs on customer sites. The app is >programmed in v5.2, uses CA Tools, linked via Blinker v3.1. A user has >all rights to the directory where this app resides on their server; >required by application. Yesterday, a user used MS Excel to link a >spreadsheet to the app files; changed the structure of the files they >had linked; destroyed the files.

>I would like to be able to password protect the files and/or the >directory and only give this password to the app program which would be >the only EXE to have access to these files.

>Does anyone have any ideas or suggestions ?

>It would be nice to be able to somehow lock out all of those tools that >exist at a customer's site.......a little knowledge has now become a >deadly thing.

But profitable for you Ray. I would charge them BIG-TIME to correct the mess. They might think twice about doing it again.

Practical solutions:-

1. Rename the .dbf files as .dum so Excel will not recognise them straight off. You then simply use .dum as if it were .dbf.

2. Alter a single byte in the .dbf header after you close each dum/.dbf. Reverse the process just before opening the file.

3. Open the files exclusively, so they cannot get at them while your application is running.

At the end of the day, the customer wants something that your current application does not do...talk with him and see if you can get an additional contract to write what (s)he needs.

Hope that helps,

Regards,

Ross McKenzie ValuSoft Melbourne Australia

Sun, 28 Oct 2001 03:00:00 GMT

Ray#4 / 5

Clipper File Security On WIN NT

Quote:

> 2. Alter a single byte in the .dbf header after you close each > dum/.dbf. Reverse the process just before opening the file.

Good suggestions except for this one. As soon as one legitimate user opens the file, the byte is reset for all other users. They'll figure that out quick.

Ray

Sun, 28 Oct 2001 03:00:00 GMT

M MURC#5 / 5

Clipper File Security On WIN NT

Quote:

>I have an application that runs on customer sites. The app is >programmed in v5.2, uses CA Tools, linked via Blinker v3.1. A user has >all rights to the directory where this app resides on their server; >required by application. Yesterday, a user used MS Excel to link a >spreadsheet to the app files; changed the structure of the files they >had linked; destroyed the files.

I have added an "EXPORT" feature to all of my apps. It creates a dbf, query.dbf, that the client can use. In the old days, it would fire up Q&A, Quattro Pro, or some other program automatically. Of course, they paid for this feature.

It is helpful before the sale because a lot of people are afraid that your new app will not be "Flexible". You can always tell them that they can get whatever they want in Excel, or Access but to leave the core database updates to your program.