Update Main Doc from Response Doc

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

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

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.

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.

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.

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

Oops sorry Sjef, you already mentioned the view.

I "forgot" the single category embedded view, because I think they're rather clumsy to work with. I don't particularly like embedded things...

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?

AliciaVee,

> most good developers don't ever use response doc

Would that disqualify me??

Sjef ;)

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

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

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.

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?

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

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
 

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

Sjef,

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

How do I do that?  This might work!

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.  :(

Thanks :)  So it works? Great!

sjef,

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

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

AliciaVee