Profiles..... like always

HCL Domino Domino Forum
1

Hi to you all…

I was wondering about the well-known profiles problem.

I designed a db, which has a profile document, for translation purpose,

created with a single key, the form name.

According to the user who wants to update it, the data ain’t the same,

although the profile collection returns only 1 doc.

I didn’t check the UNID, but according to previously done apps, it appears to

be the same.

I tried everything possible, in order to clear the cached datas… but nothing.

Am I wrong, assuming that a single key (form name) is sufficient for profile sharing ?

(I read the Help, be assured of it ! :wink: )

Does a hard way for killing caches exist, in order to avoid this issue ?

[my customer, 4 times tyre winner this year, is waiting for my app … lol !!! ]

–ian—>>

2

Subject: Profiles… like always…

I was wondering about the well-known profiles problem.

What well-known profiles problem? Maybe it is below.

I designed a db, which has a profile document, for translation purpose,

created with a single key, the form name.

I do not understand what you just said. This may be the cause of all of my further questions/comments. What does “for translation purpose” mean? What are you calling a profile document? The kind that you get a value from by using @GetProfileField()? Or just a lookup document…some document with a key for looking it up in a view that will provide data for another purpose? I am thinking you mean

this latter kind.

According to the user who wants to update it, the data ain’t the same,

although the profile collection returns only 1 doc.

The user wants to update what? And what data aint the same as what? Profile collection? I guess you are doing a getalldocumentsbykey for a notesdocumentcollection?

I didn’t check the UNID, but according to previously done apps, it appears to

be the same.

The UNID must be the key?

I tried everything possible, in order to clear the cached datas… but nothing.

I’m sorry, Ian, but I really am not getting what you are asking. I want to help, if I can.

Am I wrong, assuming that a single key (form name) is sufficient for profile sharing ?

(I read the Help, be assured of it ! :wink: )

Does a hard way for killing caches exist, in order to avoid this issue ?

[my customer, 4 times tyre winner this year, is waiting for my app … lol !!! ]

Oh, now I see the key is the form name, not the UNID? What is “profile sharing”?

If I am missing something simple that would put me on track with your questions, please let me know.

I will keep an eye on this thread.

  • Matt
3

Subject: RE: Profiles… like always…

Hi

Is it a week-end joke ???

If you don’t know what a profile document in Notes is, please read the Designer Help before posting…

Thanks in advance.

Regards

–Ian–>>

4

Subject: RE: Profiles… like always…

Yannick/Ian (cannot tell how to address you)…

Forget it. I was seriously wanting to help you, but I don’t think I want to spend my own personal time trying to help someone who doesn’t want to be helped.

A profile document can either be a single one for an entire database, or a single one per person.

You mention a “profile collection” returning only 1. And the data ain’t the same.

Your questions are totally confusing. So I am going to let someone else see if they can help.

5

Subject: RE: Profiles… like always…

HiExcuse me if you found me rude, but your questions were confusing me too.

I was talking about a single profile, one for whole database.

i.e. with 1 single key, which is the form name.

BTW the 2nd key, optional, may be something else than the user name.

I create my profile document with only the form name,

when I test the database with a ProfileDocumentCollection,

it returns only 1 document, that is correct.

But when I try to access the profile with @editProfile, and only the form name obviously,

the content ain’t the same from a user to another…

The cache is known to be a recurent problem while working with profiles,

but in that case I don’t understand the behavior.

Is it more clear ?

Thanks

6

Subject: RE: Profiles… like always…

Sorry I had such a rough response myself. Caught me at a bad moment.

OK, now to the profile document problem. I have never had this problem. So I did a quick scan of the forum and I see the problem cropping up here and there.

The only sure way around this seems to be using a regular document instead of a profile document.

Unfortunately, that would mean quite a bit of work on an existng database. You would have to find every piece of code and formula referencing the current profile document and changing it. You would have to modify every view to make sure this new document was excluded.

Good luck. I thought I might be able to help, but I have not seen this, and from what I am reading, it is kind of hazy as far as whether or not it is a basic Notes bug, or just some caching concept that has not been fully explained to the point that you can actually control it reliably.

7

Subject: It’s cached and that’s what is causing problems

Hi Yannick.

To put it simply, profiles are cached locally, so users may have different data in the profile document. The cache is refreshed when the client is restarted. To avoid such issues, Matt has the ideal solution: a configuration that is a standard document.

Profiles are great for data that doesn’t change often. I use them too for bultilingual apps (field labels, mainly) and it is OK if users don’t get the changes that were made right away. For more critical config info, I use a standard document.

Hope that clears the situation.

Lache pas la patate !!!

8

Subject: RE: It’s cached and that’s what is causing problems

Hi both

Matt.

I figured out using standard docs, but in that case it is not acceptable… :frowning:

Benoît,

Even when restarting the client, it do not work… that is the point.

I have being coding in LS (and so many others…) for years, and I do not understand the behaviour. Really… :(((

Thanks to you… I will send my app AS-IT-IS to my customer (a 4th time winner this year, lol) and, hasta la vista.

[hope they will not have to change anything…maybe will it work]

ian