I have a form with a computed when composed field containing #NoteID in it.
I then want to display that field in a view which is being exported to Oracle ( the NoteID is acting as a key)
The problem is sometimes during document creation the field stores the NoteID value but the view displays NT00000000
Any idea the cause, and how can I refresh the documents with the issue?
You can't get the real note id of a document until after the document is saved, so #NoteID in a field won't produce a useful result until after saving.
I suggest not using a field at all, and instead having the view column formula as #NoteID.
Also: Don't rely on note id if you have replicas of the database.
The same document in a different replica can have a different note id.
If you need an id represented as a string that remains the same across all replicas, use the formula #Text(#DocumentUniqueID).
Related
Created a view and added to DAC and can view correctly in Generic Enquiry. However when added in Report Designer it returns correct number of rows but the data is just repeated form the first row. Any ideas?
Ensure your view contains CompanyID field and DAC has proper key(s) defined.
My view is one application and a required form along with few fields are in different application.
Point one: A View's selection formula does not "select a form". It selects documents. These documents are (usually) created with a Form, and they (usually) contain an item called "Form" which contains the name of the Form that they were created with. So a selection formula SELECT Form = "Foo" means that the view will show all documents with an item named Form that contains the value "Foo".
Point two: A View can only select documents that are in the same database that contains the View. It cannot select documents that exist in another database.
Ergo, there is no possible forumla that selects documents in another database that were created with a given Form.
I'm assuming you probably have some keyword documents in a different database, and you'd like to use a key in the main document to pull some matching information from the keyword database. In other words, you'd like to do a "join" in your Notes view.
You can't do this, never mind whether the documents are in the same database. This is not a relational database.
There are options, however.
You could create a "user definable" column and automatically update the column formula in a profile document so that the formula can calculate the keyword correspondences. You would have a periodic agent look at the keyword database and construct an updated formula such as, #Select("a"; "b"; "c";...; ChoiceNo) to convert the number field ChoiceNo to the value "a" (for 1), "b" (for 2), etc. If you can write a formula to display the correct values for the current keywords, this is workable provided the list never gets too long.
Domino servers are capable of accessing a DB2 relational database to construct a view index, using a feature called DB2NSF. So you can actually do a join -- but your NSF data has to be stored in DB2 as its back-end, rather than beinf stored in the NSF, for this to work. This is probably going to be more work than it's worth to you for this application.
If it is an XPages application, you can create your own data set however you like for feeding to a repeat control.
I am trying to simplify an existing Notes Form in an application that I am converting to XPages. The Notes Form has over 240 fields on it and a bunch of logic that I want to clean up. Plus the form has all kinds of display formatting that makes viewing it complex. So what I have been trying to write an agent that will get FormA and cycle through all the fields and copy them to FormB. I will then use FormB to bind my XPage to and trying to track down data issues will be much simpler. If the FormA didn't have so many fields I would just recreate it manually, but I'm sure with over 240 fields I would introduce some new typo errors.
You don't need to do anything with your form in order to create a XPage layout for it.
XPAges don't need a form at all, although it makes development easier, as after creating the data binding all fields from the form are available and can be dragged and dropped to the Xpage. Fields that are not on the form have to be created manually in the source code of the xpage (e.g. copy and paste an existing one and change the binding/name)
If you want to clean up your documents, an agent can do this without even touching the form.
For this task please consider the difference between a "Form" and a "Document".
A form is a design element that defines the look and feel of a document.
Forms contain fields that define what type of data you can put in your documents.
A document is a stupid "container" for items (not fields). It contains items for any field on the form that existed in the form when the document was created / last saved. PLUS items that are created any other way (e.g. Using formula or lotusscript agents) or that have been on the form in an earlier stage of development.
If you remove a field from a form, it will NOT be removed from the corresponding documents, not even by saving them. But If you add a field to a form, the document will have an item for that field after saving (forever, if you don't remove it manually using an agent).
With this knowledge you can simply create a new, "cleaner" form with the same name as the old one and rename the old one. From this time on, document will be displayed with the new Form and you can develop your XPage using it as your data source.
If you need to accumulate the data in the documents, this can be done with an agent without using a form: just manipulate the document DIRECTLY.
Here is an example in formula to put two fields together:
FIELD NewFieldName := OldField_1 : OldField_2;
FIELD OldField_1 := #DeleteField;
FIELD OldField_2 := #DeleteField;
I think, in most cases it's not a good idea to have a form with 240 fields. It looks for me like a form from old Notes 3 or 4 times when no embedded views were available and one to many relations were put into fields with index e.g. 1 to 20.
Maybe, a redesign is a better way to go.
Also, you don't need to create and maintain a form with all 240 fields for developing your XPage. Actually, you don't need the form at all. With a data source definition based on "Domino Document" you define a form name and which way you want to create a new document or find an existing document. That's it. Then you can create your fields in your XPage. Give them a name and a type. You can do this in Designer UI. Just write the new fieldname into "Bind to" for selected "Data source". Select in "Display type" a field type (String, Number, Date/Time). That is not only valid for display but will save the field as selected type to document too. In this example it will create a new field "YourNewField" and will save it as a integer number.
When you submit the page all fields will be created or set in document. You can check the fields and their types in Notes client using the document property box.
A good way though is to create the form with the most important fields. Then you can open the document in Notes client and check the fields set by XPage.
I have a site powered by ExpressionEngine 2.5.x, using Freeform, integrated to post form data to MS Dynamics CRM 2011. The extension is nicely scalable, I can change the mapping, all that excellent stuff. My problem is how to find mapping values for Lookup fields in MS Dynamics.
I am trying to map form fields from the site forms, into MS Dynamics. Some of the fields are Lookups, in MS Dynamics. Our mapping calls out the numerical value of the Lookup item, rather than its name. (Which is good, because ppl can change the text names in the MS Dynamics console without breaking the mapping.)
My question is: I know how to find the actual back-end field names of form fields within MS Dynamics. But how to I find the numerical values of the picklist items and lookup fields? Say I have a Lookup field, for Lead Source (called campaignid). The items are:
web
online
radio ad
flyer
word of mouth
other
I know that when I edit options in an option set, I can see their numerical value. Where can I edit options in a lookup field? I've tried looking under Settings > Customizations > Customize the System, but didn't see anything called lookup.
Lookups are pointers to entities. They do not have numerical values like regular option sets. So I guess that you will have entity called Campaign (or lead) so you can check which campaigns exist in the crm DB where each entity will have view in the DB.
Let's see if i understand your question. You don't have a Lookup option like Option Set because a lookup is consequence of a relationship 1:N between two entities. So for edit a lookup you need edit a record of a entity. In lookup fields you don't have numerical values, you have guid that represent individually a record, so in a record a lookup is stored in database as a guid. Check this video.
Check here how find this guid with the record open.
A look-up field is, roughly speaking a pointer to en entity (in C# it's referred to as EntityReference instead of Entity) and it consist mainly of a guid and logical name of something.
Usually, in the code, when you have an entity, in order to access the fields of its lookup-connected entity, you'll need to make an extra query for that.
So, if you have a Contact instance and need to see the address of its parent customer, you'll have to get the guid and logical name (in this case it'll be Account) and retrieve the data for it separately.
EDIT:
Suppose that you have created an instance of Contact entity and you'd like to access its lastName field. Then you can simply refer to it as follows.
var value = Xrm.Page.getAttribute(“lastName”).getValue();
On the same form, there's also a field that refers to an Account instance (its name is parentCustomerId. Suppose now that you'd like to get the fullName field of the Account. One could expect the following to work.
var account = Xrm.Page.getAttribute("parentCusomterId").getValue();
var name = account.getAttribute("fullName").getValue();
However, that's not going to work, because the parentCutomerId is a look-up field. It means that it only contains a guid (a pointer, a reference) identifying an other entity. You'll have to use it (the guid) in order to fetch the instance that the look-up is "mentioning". Then you'll be able to check it's properties.
I have form "A" which there is a field that I need be computed after composed from Form "B". The forms are in the same database. I am not sure if it would be better to have the Form "A" field compute after composed from a "View" that uses the Form "B" or what would be the best way to get the field populated.
I have tried to do a #DBlookup, with no success.
Thank you!
Forms do not contain information, only documents do. Forms just represent information stored in documents.
Assume you have a view with name: "viewName" and it displays a set of documents.
The first sorted column of this view contains key values.
We want to get value of field someField by key from this view.
Create a new form, create a "Computed when composed" field and set the following formula as value:
#DbLookup("":"NoCache"; #DbName; "viewName"; "keyValue"; "someField");
It will access view "viewName" in the current database, get a document by "keyValue" and return value of field with name "someField"
I have tried to do a #DBlookup, with no success.
Well, what went wrong? Why didn't this work? When do you a #DbLookup call, you need to provide a view, a "key" and the field or view column you want to pull back from the matching document. Assuming you have a key with which you can link document A and document B, the look-up should be pretty straightforward.