• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 410
  • Last Modified:

Update Main Doc from Response Doc

Experts,

I have a database in testing and so far, for the most part -- all is working fine (my first almost production datbase in Notes).

I have a main form -- Project Details.  I have a response doc called Project Update.  There are 4 fields on the update form that feeds the main form.  So, if a Project has 6 updates (responses) the user can always view the latest information fed from the update form -- directly on the main form (this also helps me to construct views).

The problem is that whenever I create an update to a main document -- the updates feed to the main form as expected.  So far, one user has added updates on two different projects and the main form has not received the data from the response/update form.  I have no idea why?

I have the following code in my PostSave event (this is a client app --- not a web app) (the PU means Project Update field/form)

@SetDocField($Ref; "FeasibilityP"; FeasibilityPU );
FeasibilityPU;
@SetDocField($Ref; "ProjectPhaseP"; ProjectPhasePU );
ProjectPhasePU;
@SetDocField($Ref; "UpdateCommentsP"; UpdateComments );
UpdateComments;
@SetDocField($Ref; "DateUpdated"; UpdateDate );
UpdateDate

Anyone have suggestions?

Thanks in Advance,
AliciaVee
0
AliciaVee
Asked:
AliciaVee
  • 8
  • 8
  • 4
  • +2
1 Solution
 
HemanthaKumarCommented:
The formula looks fine.. It could be a usability error..

eg; I have main form open and then open response doc and do some updates...come back to main form save with some changes. Subsequently my response changes are overwritten. So you have to closely watch what that particular user did.

In your testing does the value gets updated ?

~Hemanth
0
 
Bozzie4Commented:
The user needs of course at least Author access to the Main document (Author / authors field or Editor).

You can simplify your code a bit (and I prefer to use @text for $ref):

@SetDocField(@text($Ref); "FeasibilityP"; FeasibilityPU );
@SetDocField(@text($Ref); "ProjectPhaseP"; ProjectPhasePU );
@SetDocField(@text($Ref); "UpdateCommentsP"; UpdateComments );
@SetDocField(@text($Ref); "DateUpdated"; UpdateDate );
""

If it doesn't work, you may consider doing this with Lotusscript, because this would make it easier to log what goes wrong.

cheers,

Tom
0
 
AliciaVeeAuthor Commented:
Hemanth,

Yes, in my testing -- (just me??) it works.

Bozzie -- I think you nailed it?  Damn!  No -- I have the main document controlled by an Authors fiedl.  So, when a user submits a project -- they can no longer edit the information (only a handful will add sales data in the main form).  Otherwise, updates are added to the project by submitting a Project Update, as I have described.

So, are you saying then that since my users do not have access to EDIT the main project anymore, then they won't be able to push their Updates data == via the SetDocField command?

Yikes -- what to do now?  Help!  Is there a way where I can use LS to temporarily give the user edits rights -- upon PostSave only? and then once they (or anyone) opens the project -- the EditRights field gets flagged back.?  Help!!

Am upping the points for a solution -- quickly.
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
madheeswarCommented:
May be with Schedule agents can work in the backend. if u think it should take immediate effect in the main doc, then u should give proper access to the main doc untill they update. Once it is update u remove names in Authors field.

0
 
Sjef BosmanGroupware ConsultantCommented:
Storing the same information in two places should be avoided, even in Notes. It's always best to aim for a high level of database normalization. In this case, I'd never try to update the main document. Instead, my approach would be either to use a view and a @DbLookup to find information from the response document to be displayed, or I'd use LotusScript to go through the document.Responses and get the data. I'd use multi-value fields to display the data.

This way, there will be no redundant information in the database. If ever the parent-child relation is broken, the document will still contain consistent data.
0
 
Bozzie4Commented:
Yes, the problem is Edit rights to the project document then.  You can work around this using agents that run on server, "run as " an administrator, and are triggered by Document Saves.  

If you take the Sjef approach, you will avoid the problem (which is preferable)

Another possibility along the same lines as Sjef proposes, is to use an embedded view in the project document, where you show the responses (using 'Show Single Category") .  

cheers,

Tom
0
 
Bozzie4Commented:
Oops sorry Sjef, you already mentioned the view.
0
 
Sjef BosmanGroupware ConsultantCommented:
I "forgot" the single category embedded view, because I think they're rather clumsy to work with. I don't particularly like embedded things...
0
 
AliciaVeeAuthor Commented:
All --- thanks for your great comments.  Yes, I can see how I've gotten myself in a jam -- but again, this is my first Notes application, so I have a lot to learn about set-up and display of data.  I used Main Doc / Response Doc structure, and even at this point (after reading several manuals and speaking/emailing other developers) most good developers don't ever use response doc -- only main docs!

So, at this point, I am only adding the data from the Update doc -- for convenience -- as a nice to have.  Not critical if I loose this.  

Is there an easy way, at this point to push the data from the update form -- postsave -- where it will allow edit rights to the main doucment, for that short time period?

I'd need it where it happens as projects are updated -- or I guess a nightly agent on the server would work too?  Can someone post an example script?
0
 
Sjef BosmanGroupware ConsultantCommented:
AliciaVee,

> most good developers don't ever use response doc

Would that disqualify me??

Sjef ;)
0
 
AliciaVeeAuthor Commented:
Sjef -- no -- but that definetly disqualfies ME!  Ha ha.  This is what I hear.  Do you agree?  Someday I might get to that level, but for now, this application I am building is Main/Response -- and another one which I have started is also the same.  I need to better understand this concept -- but I do see how, for some views, it is easier when all docs are main (to display totals that come from response docs for example).

So, what do you think I should do about my bug/issue with updates not being pushed to the main doc?

AliciaVee
0
 
Bozzie4Commented:
It's not really necessary that it's a responsedoc, this just makes it easier to work with.  If you can identify which related documents belong to the "main" document, that works fine too.

Response documents definitely have their uses and advantages, but you should only use them where appropriate.  So I totally disagree with your statement.

cheers,

Tom
0
 
Sjef BosmanGroupware ConsultantCommented:
Ah! I agree, but with Tom in this case :) . Responsedocs have their advantages, but they can be a pain in the butt as well sometimes, especially when you have to maintain keys in all documents for other views, i.e. non-hierarchical views. What you need to know is that you can always use ANY document in any view that is NOT hierarchical (properties, 2nd tab, Show responses in a hierarchy NOT set). It is not possible to show response documents on the main level in a hierarchical view. So if you have a hierarchy like A->B->C->D (D being the grandchild of A), it is only possible to show exactly that hierarchy in a view, and not only B->C->D.

To maintain the keys, more or less like in a relational database, I created a set of functions (in a Class) that will help me walking through all the children to modify key fields when necessary.
0
 
AliciaVeeAuthor Commented:
Tom,

Okay -- well its good to know that what I originally stated is NOT the rule of thumb, especially since I do not practice it (not now...maybe never??  who knows?)  If I don't get this app working correctly, it just might be the last application I try in Notes (ah...good old MS Access!!)

Sjef -- very good explanation -- yes, I understand now a bit more.  Thanks for the details.

So -- no solutions for me to try?
0
 
Sjef BosmanGroupware ConsultantCommented:
AliciaVee,

> it just might be the last application I try in Notes

That would be our fault, for not properly explaining to you how it should be done. That's putting a load on our shoulders. :)

Temporary postsave rights? Interesting idea... You could accomplish that using an agent that's allowed access to all main documents, but I think it makes things very complicated. BAck to my original suggestion: don't change the main document, but put something in the main document's postopen that gets information from all children. That could be done several ways:
- an embedded view (but I don't like them)
- write some LS that goes through all Responses of the document
- write some LS that opens a view and gets the info from that view (should not be hierarchical)
- or do something similar using a @DbLookup in that view in a computed-for-display-field (easiest way)

Why do you want the info to be pushed up to the main doc?

Sjef
0
 
AliciaVeeAuthor Commented:
Sjef,

Yes, you are right and I see where you are coming from -- its not ideal what I really want to do -- and again, it is not critical, just a nice to have.

The main form is a project form that gives most of the information -- only items missing is the current status of the project, which is a moving target and goes through phases based on what is added from an update form -- the response doc, which also captures the Status / Feasibility / Comments of the current project.  These updates will be added from time to time, and if someone looks at the main project form -- which holds the critical information, it would be nice to know what is the current status -- and what were the last comments added to this project, both of which would be in the updates  -- the response to main doc.  Instead of scrolling through the last response doc, or better yet -- needing to go to where I have response docs displayed to get these two pieces of information -- it would be nice to have it in the main form.  Most of the views I have are designed to display critical project information and are also using the totals feature since we are tracking dollar amounts.  Having response docs in these views would not be practical and would make it way too busy.

So, thats where I am -- I'd like to have LS agent -- but since I'm fairly new to building Notes apps, I'm not real comfortable with it.  I searched on the web and came across a great resource to add to my knowledge, and maybe there is an agent I can tweak to do as you mentioned:

http://cseh.best.vwh.net/lssamples.html

I printed the document and its like 125 pages -- I really hope to find something in there.  I also have 5-6 manuals and in reviewing them I could not find an agent that I think I need -- I also have Inside LotusScript and Practical LotusScript -- great snippets of code -- but not what I am looking for.  This makes me think what I'm asking for is extremly specialized -- can that be?  Dag!

AliciaVee
 
0
 
Sjef BosmanGroupware ConsultantCommented:
Ah no, it's not very specialized at all. It's just that one needs to be very careful when introducing redundancy in your database, i.e. storing the same information (or derived) more than once in different places. You actually named one very valid reason for duplicating info from a response document to a main document: you want to show it in a simple view. If you want to add values in a hierarchical view, that's easily solved, but you'd really have to get familiar with the ideosyncracies of a responses view. Most importantly: all columns to the LEFT of the column with "Show responses only" are applied to all documents, all columns to the RIGHT of the responses-column will contain data from main documents only.

Just the issue about the rights in the database makes it complex, the fact that a response document updater needs to be able to write in a main document. That's why I suggested not to update the main document, but let the main document's form find the info for itself when is is opened. Only if you want a flat view with only up-to-date main documents, then you have to do the impractical. In all other cases, make them use a collapsed hierarchical view, with total columns at the left. Or make a simple view, with the documents sorted as if they were in a hierarchical view, and put your columns wherever you like.

Since you seem to be convinced that you need an agent (that runs with a delay of 15 minutes), here some ideas:
    make the agent run when documents are created or modified
    for all modified documents
        if the document's info is to be reflected in the main document
            get the main document (use Parent ID)
            update the fields
        end if
    end for
0
 
AliciaVeeAuthor Commented:
Sjef,

Hmmm -- "...let main document form find the info for itslf when it is opened..."

How do I do that?  This might work!
0
 
Sjef BosmanGroupware ConsultantCommented:
Worse: this works!

There are at least 2 ways to do this:
- using a view with the sub-documents, or
- with the Responses property of the main document

For the first method, i.e. with the view, the main and the appropriate response documents have to share a key, that is UNIQUE for the main document. With that key, you can create a view of only response documents, that is sorted by the same key as the main document plus with additional sorting information. This view can then be scanned using either
    @DbLookup(..... "view"; main-key; ....)
which will return one or more values as a list of strings, or in LotusScript using
    view.getalldocumentsbykey(key, true)
that returns a documentcollection of all child documents sorted by the views sorting criteria.

The second method is the crude way, it looks like the LotusScript-version of the view-approach, but the documentcollection you get is directly retrieved from the main document's Responses property. Several drawbacks: the responses in this case are not sorted in any way, and you have to retrieve entire documents. As you might know, if you include the right columns in your view, these values are accessed quicker using the ColumnValues of a document retrieved from a view. NB I assume these values also work for the collection returned by the getalldocumentsbykey method.

23:26 over here. Groetjes, en tot de volgende keer. :)
0
 
AliciaVeeAuthor Commented:
Sjef!  Wow -- late -- go to sleep!

Ugh...okay -- get the concept, but don't forget you are dealing with a newbie here, so I don't know exactly 'how' to do what you are describing.

So, by building a lookup view -- this will allow my latest update from my response doc, to be added to the field in the main doc, when someone actually opens the main document?  I'm confused.  :(
0
 
Sjef BosmanGroupware ConsultantCommented:
Thanks :)  So it works? Great!
0
 
AliciaVeeAuthor Commented:
sjef,

Yeah...took me a while -- but it is working great now.

thanks again, for your help.  I'm learning so much!

AliciaVee
0

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 8
  • 8
  • 4
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now