Is MSWord Document Open 2

[wsjames]

I have an application that launches an MSWord.doc. Pending the user, the document(s) are opened readonly or read/write. Is it possible [within VFP 9.0] to determine if the MSWord.doc is already opened by another user. I don't believe the [GetFileAttribute] function offers this option.

[My apologies that I posted this in the General Coding area, the Site Admin indicated I should post here.]

 

[bborissov]

Check thread184-1538667

Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.

 

[white605]

I use the following code to determine if a file exists, if not create it, saveas, and leave it open. This isnt what you want but may be a start as it has to exist before you can determine if its open. I would guess there will be a "documents" collection in word that you might could enumerate and test.

*check to see if document exists - if not create it by opening the dot hobt.dot or wobt.dot stored in cfilename above h or w
If .Not. File(&cobfilename)
	loDoc  = loWord.documents.add(&cfilename)			&& create new document based on template file
	loDoc.SaveAs(&cobfilename)					&& save with the correct name

This old world keeps spinning round - It's a wonder tall trees ain't layin' down

 

[white605]

Borislav,
your a second quicker, and a better link that me.
If fopen retures -1 i assume that would mean its not there or its already open. is this correct?
wjwjr

sorry, put this in rong thread first time

This old world keeps spinning round - It's a wonder tall trees ain't layin' down

 

[bborissov]

Yes,
FOPEN() tries to open the document.
If it is failed that means that you have trouble:
1. File doesn't exists.
2. File is already opened by another user.
3. You have NO read/write access to the folder where that file resides.

Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.

 

[TamarGranor]

White605 -- FWIW, you don't need the macros in that code. If those are variables containing the relevant file names, you can just pass them as is. (Now, if they're variables containing the names of variables that contain the filenames, then the macros are relevant.)

Tamar

 

[white605]

Tamar,
Thanks, That was old code, but I think i took several steps to build a filename, from information in the dbf, sorta like
lastname.firstname.{TypeOfDocument}.{ReversedCaseNumber}.doc
so, cobfilename and cfilename should be string values...ill change the code and give it a try.




This old world keeps spinning round - It's a wonder tall trees ain't layin' down

 

[wsjames]

Thank you very much for the options. I will put them to use.

 

[Imaginecorp]

The only problem I see with the Fopen() is in a multiuser environment and the document is on a server.
When you open the document on the local machine, which word will do, Fopen() will return a negative. But another user can successfully open it on theirs. If changes are made whoever saves last will have their changes saved.
Another problem is one user opens a doc within your app, the second user opens it within Word, and again whoever saves last gets their changes saved.
If you are allowing users to open and edit a document within your vfp app, I would strongly recommend you really think about every scenario.
We do this in our app.
We convert the document (doc, exl, pdf etc) to a string using Filetostr() and save in a memo field in a table on the server. When a user calls it, it is reconverted back and is opened on the local machine. At the same time the users id, with the doc number is stored in a table, again on the server and when done the id and number are removed.
Now if another user wants to open that doc, the table is checked, if the doc is already open anywhere on the network, a message is displayed and if needed the doc is opened Read-Only. The second user has the option to send a message or call the first user etc.
All of the above is depended upon how complex your app is…

 

[bborissov]

Imaginecorp,
WHY???????
Why should you keep documents on LOCAL machine?
Check this:

http://www.foxite.com/faq/default.aspx?id=26

Even if Ken talks about Images the same is valid for ANY other file types DOC, XLS, PDF etc.
I have one rule DO NOT SAVE external files in Database. Save them on Server (you have full access to your folder isn't it?) and save only path to them in your tables.

Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.

 

[Dan Freeman]

Whoa, hoss! Any time I hear "multi-user" in a Word discussion it's time to step back.

WORD IS NOT MULTI-USER. If a document is already open, the second user who tries to open it will get a read-only copy (along with a message about another user having the file open).

There is actually a FAQ in the Word support groups about this because Word sometimes leaves its semaphores on disk when it crashes and won't let *anyone* edit the doc.

If you're talking about making a local copy to subvert Word's built-in behavior I'll join Borislav and ask WHY?!?!?!?!?

 

[Imaginecorp]

Borislav; the documents are Not on the local machine But on a server as a string in a VFP memo field. Why: because in our case our clients like to store (save) customer invoices, asset inspections etc etc. Rather than create folders for each customer or asset on the server and then assign permissions for each folder to applicable groups (operations, finance etc) we keep the documents in a table with a link to the approprate customer, asset etc...

Dan; lets look at this scenerio: A word document is sitting on the server in a folder, VFP through automation opens it. The document is opened in the Local copy of word on the users machine. Another User opens the same document, via VFP automation, that too Will open on his local machine. Now a 3rd user opens the document using word, the doc will open as well. All without being in Read Only mode.
In this scenerio Fopen() will return the handel for both users using vfp automation.

 

[bborissov]

Imaginecorp,
When you create SUBFOLDERS of your Data folder ALL groups that have rights to use your data folder have the same rights over the SUBFOLDERs, so you don't have to create ANYTHING but subfolder.
Saving documents on table is NOT the right approach. What will happens with these documents of your table is going corrupted? All gone.
Also VFP has limit to 2 GB for each file. 2 GB is not so big when you store files in tables. What you could do when you go over the limit? You should check every time when you try to save a file in table IF the FPT file is near 2 GB and what will be new size when you put the new document there.

Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.

 

[Imaginecorp]

Trust me Borislav; It works for us, has been for the last 3 years without a flaw... There are a lot of failsafe checks built into the app regarding the size limit and table corruption etc etc.
Like I said in my first post something like this has to be throughly thought out and the absolute correct design put in place...

 

[bborissov]

Your application, your choice.

Borislav Borissov
VFP9 SP2, SQL Server 2000/2005.

 

[Imaginecorp]

Borislav; All your points are extremely Valid and I agree with every one of them and gave them very serious thought 3 years ago, but for what we do and what our clients want, our way works and is a major selling point for our system. Thanks though...

 

[Dan Freeman]

Imaginecorp, if the documents are sitting on a server and three users open the doc TWO OF THEM WILL GET READ-ONLY COPIES! That's built into Word.

Word is NOT multi-user.