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.
Related
I'm creating a compliance mailing for my organization, the mailing will include merge fields that identify the office location, physician, and SiteId. The mailing will also include a table of information that is dependent upon the particular SiteId.
I'd like to use the import table function of MS word and set up a query that references a merged field (SiteId) so that the inserted tables populate the appropriate data for the particular site. I'm unable to do this.
How can I set up this document so that I can import only records from my source (an ms access query) that match the SiteId merge field?
Word's mail merge does not support one-to-many relationships. There are ways to coerce it, but only one of them can yield a table as a result and over the years it has become less and less reliable as Microsoft has not regarded it as important enough to maintain...
What you need to do is set up a query that provides ONLY the information you want displayed in the table, plus the key (SiteId). It's best to sort it so that all the SiteId entries list together, and are in the order the data will come through in the mail merge data source.
On the Insert tab go to Text/Quick Parts/Insert Field and select the Database field from the list in the dialog box. Click "Insert Database" and follow the instructions in the dialog box to link in the data. Be sure to set the Query Options to filter on the first SiteId from the data source. When you "Insert Data" make sure to choose the option to "Insert as a field".
This inserts a DATABASE field in the document which you can see by toggling field codes (Alt+F9). The field code can be edited and what you need to do is substitute the literal SiteId value you entered for the query with its corresponding MergeField.
When you execute the merge to a new document that should generate a table for each data record corresponding to the SiteId for the record. But, as I said, Microsoft hasn't done a great job of maintaining this, so it may require quite a bit of tweaking and experimenting.
If the results are not satisfactory then you should give up the idea of mail merge and use automation code to generate and populate the documents.
You can find more (albeit somewhat out-dated) information on this topic at http://homepage.swissonline.ch/cindymeister/mergfaq1.htm
I am trying to create a categorized view of all Notes documents that have a field with exact same value, i.e. there is a field for Contractor Name and I want to create a view that lists each Contractor and the documents that relevant to each. How do I do this? I have tried view formulas like the following but no success as yet
SELECT #IsAvailable(Contractorid) & #Count(Contractorid) > 1
SELECT #Count(#IsAvailable(Contractorid)) >1
Nsf databases are no relational databases. The count of different documents with a unique value in a specific field cannot be used to build a view selection formula.
You could write an agent, that runs through all documents and counts them and puts all with count > 1 in a folder, but this is quite a lot of LotusScript code and needs some advanced knowledge.
The other possibilit would be to categorize the view by ContractorId and add one column before that categorized column: simply use 1 as column formula and select "display totals" in the column properties as well as "hide details".
Then at least you have the information, how much documents are in each category, but unfortunately you cannot filter by it and you cannot sort by this column.
A third possibility would be to use an xpage interface, but that is even more work to do and a completely different story developmentwise.
This is similar to view to identify duplicates. My approach is to use folder.
Make a new folder with design of your view. Instead of (not working) selection formula use short LS code as an action, or QueryOpen event (make sure only one user runs the script).
The code should cooperate with another (hidden) view sorted by Contractorid. Make a ViewNavigator for that view and traverse through it with simple logic - if previous entry has the same Contractorid as the current one, put both documents into folder**. That way you will get list of all documents with duplicate Contractorid. Make sure to wipe all the current content from the folder at the start.
** This can be optimized further by slightly more complicated algorithm to handle first duplicate diferently - for more than two duplicates this algorithm makes extra calls of PutInFolder method.
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 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.
Any one has any idea how to map an infopath field to a sharepoint column of type choice? The infopath field is a repeating field, so the user can select multiple options, I want to be able to map those to the choice field in sharepoint. Any ideas?
update:
What I'm trying to do is the following. I have a choice column in sharepoint which allows user entered values. In infopath, I have a repeating field. I'm binding the field to a dropdownlist. The dropdownlist gets filled by a webservice. This dropdownlist is in a repeating section, so the user can choose to select from multiple dropdownlists. So lets say the user adds 2 dropdownlists, and selects an option from each dropdownlist. I want to be able to add those selections as choices in the sharepoint choice column.
SharePoint list is a flat structure, and because of that Infopath does not allow you map repeating sections to list columns.
You might wanna consider the following workaround:
Store Infopath form to one library
(along with non-repeating fields)
Use one of these custom activities to extract data from
repeating table and copy it to
another list
Create a custom data view or a web part to display these items (if
necessary)
This approach can be useful if you need to do some additional tasks with the repeating data.
When you are promoting fields within a repeated section into SharePoint columns, the options available are to promote the column as:
first (i.e. only the first selection is promoted)
last
count
merge (I believe this merges all the selected values together into a single entry)
screenshot http://img4.imageshack.us/img4/5539/repeatinggrouptr3.png
Is it not similar to Create a Repeating Cascading List from:
a Flat Data Source or
a Hierarchical Data Source ?
If it is, may be those two articles may give you some pointers.
Depends on the type of choice field it is.
If it is a Multiple Select (checkboxes) Choice field, you can set the field through the object model (from the sharepoint site) or through the web service, by using ";#" for each item that you want to check mark, where is the value which is listed by the checkbox. I don't remember what the option is for single choice only, but it is something of the same nature. If you are talking about lookup fields, it has to do with the index number of the field from the list you are looking it up from. Also, there is additional steps if the choice field allows users to input or specify their own options.