Okay, I know what @GetProfileField does - but I’ve encountered a specific use of it in an app I’ve inherited that I’d like to confirm.
I have a frameset, in the top of the frameset is a form called Book, it has a field on it called BookUNID.
In the bottom of the frameset, I have Authors, and on that form is a field BookUNID. The Authors form also has an embedded view on it which lists the actual authors based on a single category from BookUNID (on the authors form as mentioned).
Now, what is confusing me is the BookUNID field on the Authors form has a selection formula of:
@GetProfileField(“Book”;“BookUNID”;@UserName)
This gets the value from BookUNID from the Book form/document and places it in the BookUNID field on Authors thus filtering the view.
Is this some unique way of using a ‘profile’ document in a frameset - as it is uniquely getting the BookUNID value from the Book in the upper frame - which is the one we want to list the authors for?
Subject: @GetProfileField Question
Think of the profile doc as any other notes document, you just can’t see it in views, and it has no form assoiated with it. So, somwhere before you get to that frameset, presumably when the Book doc is created, this profile doc is created and the vlaues set - something like
@SetProfileField(“Book”;@Text(@DocumentUniqueID);@UserName)
Then the “Book” profile doc is created if it doesn’t already exist and the ID is set for this user (in this example though it would be the same ID for every user so must be a little different)
The profile doc is available for anywhere in the db it is not restricted the fram it was cretaed in or is being read from, so again, it’s not obvious form your description why there would be a frame.
Anyway, hope this helps the thought process
Subject: @GetProfileField Question
Dont know if i understand your question good but this is how it probably works…
A profile document document can be compared with some kind of global variable or a cookie.
The @getProfileField gets this value and @setProfileField sets this value.
I guess this is used to influence the selection of your view. But there has to be a @setProfileField somwhere.
Hope this helps you…
Subject: @GetProfileField Question
Thanks for the responses so far. I understand how profile documents work normally, what I don’t understand is how there normal way of work can apply in this case.
For example:
If a profile document is being created when a Book is added - we have one profile document per Book document, this could add up to thousands which seems insane?
Also, what has the username got to do with it? The username is the key, why would the user name be the key as it then means the next guy running the software would need find the BookUNID?
Remember this is being used in frame, with the Book document in the top frame, and the Author document (with a categorised embedded view on it) in the bottom frame. Even though I’m using the software, and have never created a Book - it finds the BookUNID, in a profile document created with the Book form with an index of my username?
Hence the reason I thought it was doing something clever and assuming, when a frame applies, it looks in the document in the other frame - which I didn’t think you can do but it makes no sense any other way.
I agree with the fact I may be missing something.
Subject: Haha!
Every time a Book document is opened it creates the Profile Document indexed under the UserName - so two people can do this at once. It then uses the Profile document to fill in the fields on the ‘related’ documents. He also modifies it on PostSave.
Still seems to be it would result in a Profile Document per user for each Book document they open? Do Profile documents cease to exist on database closure? Otherwise you could end up with a profile document per Book, per user?
Looking for clean up stuff anyway.
Clever way of using them I thought.
Subject: RE: Haha!
The profile docs remain after use. I once had a db with a bug that ended up with every visitor to a web page cretaing a different profile doc. Eventually the db burst at the seams.
BTW. You can use profile docs on web pages too as they will write even if the page is a rela page not a form and even if the default access is reader not author, so you can create a hit counter for a page on the web or a log of visits from the desktop (even saves in preview - no need to edit a doc), great for when someone says “I never saw it, I never read it” you have the proof.