Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Protecting Word docs used by an application
Message
From
01/01/2009 14:15:40
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
General information
Forum:
Visual FoxPro
Category:
COM/DCOM and OLE Automation
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Network:
Windows 2003 Server
Database:
MS SQL Server
Miscellaneous
Thread ID:
01370423
Message ID:
01370498
Views:
14
>One of my clients just had an employee accidentally delete all of the Word documents that their VFP applications use to merge data for printing their legal notices. I know the users need access to the documents and to the directory where they reside in order for the application to access them, but there must be a way to protect them from modification or deletion. The client tells me that this system has been in use for 15 years and this has never happened before, but I suppose it was just a matter of time.
>
>The Word automation process works like this: the original document is opened in Word, copied and the text pasted into a new blank document. The original is closed and data is merged into the copy. After the copy is printed, it is closed without saving. This process applies to 16 of the 18 documents. The other 2 are 'custom' documents that users may edit after the data has been merged. Users are allowed to save these custom documents but the copies are supposed to go in their personal directories, not the application directory. I suspect what happened today is that the user went looking for her copy and somehow deleted all of the originals, perhaps thinking they were in her directory.

The template documents are a part of your application; they are metadata, or equivalent to .frx files, if you want. You may keep them in a different location, somewhere in ...\TheAppDir\reports or ...\TheAppDir\Templates or some such. Also, as they are Word documents, they zip with an astonishing ratio (meaning the amount of actual info in them is low :), so you may want to deliver them zipped. Then in a case like this just unzip the latest and charge them with fixing their blunder, then be generous and say "OK not this time, but...".

Yet another solution, which is less practical for bulky files (and YMMV on the definition of "bulky") is to have them all delivered in a table, then just copy out as needed. It takes about 100 lines of code and one table. For some uses (dlls which go with the app, for instance) I re-deliver that table with every update. Using zlib or other to zip individual files into memos in this table may reduce the size.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform