Calculated doc links changing to database links

I have a database that serves as a repository for software design documents. It is accessed using the R5 clients (usually 5.0.8, a few 5.0.4a stragglers, maybe some 5.0.10 users too). The software design documents fall into one of several categories, such as Functional Design (FD), Technical Design (TD), Requirements Definition (RD), etc.

The form used to "carry" the design document (as an attached Word file) has a dialog list wherein the user specifies the document type when the record is created in the database. The form has a computed subform that displays information unique to the document type on subsequent openings. The subform formula includes one subform for if the document is a new document. That "New" subform has code in the QueryClose event that checks to see if the document being closed is unsaved, and if it is saved, it checks the document type, performs a lookup against that document type, and for each document it finds, it creates a new checklist document in the database (based on the contents of the found document) and creates a rich-text item in the original document with a link to that new document plus another normal text item to display a label for the link. (Actually, it also creates a third field into which I stuff the document unique ID of the checklist document for troubleshooting purposes.)

For example, if the user creates a new FD document, when they save and close the document, the "new document" subform's QueryClose finds that there are five checklist documents defined for FDs, so it creates five new checklist documents in the database of the various types, putting links to the new checklist documents into rich-text fields CL1, CL2, CL3, CL4, and CL5, and putting labels of these checklist documents into text fields L1, L2, L3, L4, and L5, respectively (plus the doc IDs into ID1 through ID5).

The subform that loads for documents of type FD, then, has ten computed fields on it: L1, CL1, L2, CL2, L3, CL3, L4, CL4, L5, and CL5, with the L# fields being the text fields holding the labels that describe the rich-text fields, and the CL# fields being rich-text fields containing the links to the checklists. The L# fields are set as Computed When Composed so they won't ever recalculate. The CL# fields are rich-text fields that are computed with their own name in the formula.

In theory, this all works pretty well. In my testing, this all works pretty well. But I have one user who has a remarkable knack for making things blow up.

In some documents that she accesses, the links to the documents are turning from document links to database links. They then remain database links forever after for any later users.

So far, this has only occurred in documents she has created and then gone back into later. Sometimes she can create a document and go back into it, in edit mode or otherwise, many times and they never becomes database links. Other times, by the second time she opens the document (meaning, create, save-close, open, close, open), the links are corrupted. I can find no rhyme or reason, and she's not quite savvy enough to have discerned any pattern either.

It's possible that this will also be happening with other users, as this is fairly new functionality and hasn't been stress-tested yet. But at the end of week one, she's the only one to have reported anything with it, and she only found out about the new functionality yesterday while other people have been using it since Tuesday.

An obvious consideration there, if this is a user-based problem, is what kind of restrictions are on any of the documents? The documents do have an Authors field, but the Authors field is normally defaulted to "[AuthorRole]", which is assigned to all the "normal" users. (This is part of functionality where users can mark a record as in use, and other users won't be able to edit it until they check it back in.) I know she has the [AuthorRole] role assigned, because the checklist documents also have a computed authors field, and they have that computed as "[AuthorRole]" and she can edit those. She also has Author access status, with the ability to Create Documents and Write Public Documents.

The biggest challenge I'm having is that I can't reproduce the problem, and she can't consistently reproduce it. So I don't have a place to go and look for where the trouble is. She has said that the first time she opens a document (after it being closed when she first creates it), which would be the first time it opens on the document-type-specific subform, the links have always been correct for her.

I've double-checked the save and close events on the subform, and I've doublechecked the CL# field definitions on the subform (rich-text, the CL1 field is computed to be CL1, etc.), and I've doublechecked all the events on the main form that might somehow reference the fields, and there's nothing I can find.

All of which means It's probably something terribly simple that I'm overlooking.

So, any suggestions would (as always) be most appreciated. I've given it every point I have, and will boost the points up as they accrue over the next few days.


-- b.r.t.
Who is Participating?
HemanthaKumarConnect With a Mentor Commented:
Barry, The answer is right in your question

The problem was with earlier version of 5.x.. which had constantly minor bugs like this up till 5.08. In 5.x chain >5.08 versions are considered stable and reliable code pack. So I suggest you to upgrade the user client to recent one...What is that you are loosing.. it is a free upgrade afterall. Also implement version check in your app so that you can warn user that the application might not function properly.

Few technotes which describe similar problems...

BarryTiceAuthor Commented:
Ugh. What I'm losing is my mind, I think.

We've got 100+ users of this db, and (A) I'm not in our systems department, (B) I work remotely, (C) some of our users are not as quick-thinking as the computers they work at, so it will have to be one of the techs from the systems department doing the upgrades. Putting a request into our corporate help desk to have every desktop upgraded to 5.0.12 isn't going to make anybody happy, I'm afraid.

But if it's the only way, we might need to do it.

Perhaps we can just start with this one user's box, as she seems to be the only one having problems so far. Meanwhile I'll throw together the code to restore the links (using the ID# fields I wisely included...) as an agent that can be run on documents as they "break" for other users.

Any other ideas out there?

-- b.r.t.
Maybe that could be your keep building the links by a scheduled agent. One side effect though is that you can potentially create conflicts !!
BarryTiceAuthor Commented:
I put the Fix-The-Links kluge into a button that appears below the subform, under the links, saying "If the links above are blue rather than yellow, click this button to fix them."

The thing is, the text label for the links is dark blue, consistent with the text on the rest of the page. So I've already had one user click the button because the text was blue.


At least it didn't do any damage.

As promised, I've added every point I've accrued. Thanks for the help, HamanthaKumar. I would have rather heard there was something I could do to fix this, but a right answer is better than an easy one.

-- b.r.t.
I am always skeptical when rolling out the code to the user community.. that is why we follow a version level below than the user has. But in your case it is so below.. that I never recommend .

Believe it or not I am still on R5 and users are on R6.. still we get into this version conflicts...what can we do..just keep providing a workaround or at most we can deny (although I never got that privilege ) users happy !! we are happy
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.