When performing a search in Archer, the result contains some un-necessary fields. Is there a way to show only fields that belong to Application "General information" ? In other words, there are some fields that are suggested to being added to "General Information" tab which appear in a search result.
I know I can disable these fields by selecting the field, then clicking on "modify field properties", "options" and untick the show field in a search result.
Since I have multiple applications and a lot of fields, doing this will take a lot of time. Is there any script or trick to hide all these fields in a search result?
You could always use the API and create your own search XML to contain only the fields you want to see.
But short of doing that, I think you've hit the nail on the head. You'll need to go into each application and then modify each of the fields you don't want shown. I don't think it's a waste of time, as you're surely not changing this search result every time... it's a one time deal and if it makes it easier for you or the end users, it's certainly worth it IMO.
If you have access to the database then you can modify table "fielddef" and make fields not searchable by default. You can join "fielddef" table with "level" and "moduletranslation" and target only specific modules this way.
I don't have the SQL code for this since I didn't have to make a bulk update to the fields and make them not searchable.
It should take 5 min to join these 3 tables and make an update if you are good with SQL.
Related
In several notes applications, instead of handling related data as separate documents, if the size of the data is small (less than the 32k limit), I'll make several multi valued fields and display it in what I call a "List Panel". It's a table where each column displays one multi-value field. Since fielda(1) goes with fieldb(1) that goes with fieldc(1) there is a concept of rows. (I did a similar thing in my auditing routine discussed here )
It is always assumed that each field has exactly the same number of elements.
All the multi-value fields are then stored on the single document. This avoids several coding conventions that made my eyes bleed like having date changed, who changed it, new value fields for each field we wanted to audit. Another thing that this kept to a minimum was having to provide multiple fields for the same thing that locked you into a limit. Taxrate1, Taxrate2, Taxrate3, etc...
In my "Listpanel" the first column is a vertical checkbox. (One for each element in my lists) This is so I can select one item to bring up and edit, or select multiple values to delete "rows" or apply some kind of mass change to them.
What would be the best way to handle this under xPages to get this functionality? I tried making a table but am having the devil of a time to get the checkboxes to line up with their corresponding data items.
Views and dojo-grids seem to assume we're using a document for each row.....
This TableWalker may provide what you want http://www-10.lotus.com/ldd/ddwiki.nsf/dx/Tutorial-Introduction-to-XPages-Exercise-23
It was created when XPages was all very new, so it's SSJS rather than Java. But if you're comfortable wiith Java, converting it probably won't be a challenge.
You could use a repeat control to display the values and build a table using the table row tags in the repeat. You would want to calculate the id of the checkbox to be able to take an action on that selected row. The repeat var would be just one of your multi-value fields and you use the index of the repeat to get the value for that row from the other multi-value fields.
I have problems with my records within my database, so I have a template with about 260,000 records and for each record they have 3 identification columns to determine what time period the record is from and location: one for year, one for month, and one for region. Then the information for identifying the specific item is TagName, and Description. The Problem I am having is when someone entered data into this database they entered different description for the same device, I know this because the tag name is the same. Can I write code that will go through the data base find the items with the same tag name and use one of the descriptions to replace the ones that are different to have a more uniform database. Also some devices do not have tag names so we would want to avoid the "" Case.
Also moving forward into the future I have added more columns to the database to allow for more information to be retrieved, is there a way that I can back fill the data to older records once I know that they have the same tag name and Description once the database is cleaned up? Thanks in advance for the information it is much appreciated.
I assume that this will have to be done with VBA of some sort to modify records by looking for the first record with that description and using a variable to assign that description to all the other items with the same tag name? I just am not sure of the correct VBA syntax to go about this. I assume a similar method would be used for the backfilling process?
Your question is rather broad and multifaceted, so I'll answer key parts in steps:
The Problem I am having is when someone entered data into this
database they entered different description for the same device, I
know this because the tag name is the same.
While you could fix up those inconsistencies easily enough with a bit of SQL code, it would be better to avoid those inconsistencies being possible in the first place:
Create a new table, let's call it 'Tags', with TagName and TagDescription fields, and with TagName set as the primary key. Ensure both fields have their Required setting to True and Allow Zero Length to False.
Populate this new table with all possible tags - you can do this with a one-off 'append query' in Access jargon (INSERT INTO statement in SQL).
Delete the tag description column from the main table.
Go into the Relationships view and add a one-to-many relation between the two tables, linking the TagName field in the main table to the TagName field in the Tags table.
As required, create a query that aggregates data from the two tables.
Also some devices do not have tag names so we would want to avoid the
"" Case.
In Access, the concept of an empty string ("") is different from the concept of a true blank or 'null'. As such, it would be a good idea to replace all empty strings (if there are any) with nulls -
UPDATE MyTable SET TagName = Null WHERE TagName = '';
You can then set the TagName field's Allow Zero Length property to False in the table designer.
Also moving forward into the future I have added more columns to the
database to allow for more information to be retrieved
Think less in terms of more columns than more tables.
I assume that this will have to be done with VBA of some sort to modify records
Either VBA, SQL, or the Access query designers (which create SQL code behind the scenes). In terms of being able to crunch through data the quickest, SQL is best, though pure VBA (and in particular, using the DAO object library) can be easier to understand and follow.
I want to write a query which checks the input provided by the user with the column data of my table. i tried using LIKE and CONTAINS but it didnt work for me. eg my table data contains "Bar B Q Tonight" and if user enters "BBQ Tonight", how to deal with it? I have enabled full text-indexing for my table too. I am working on sql server 2005 in visual studio. can anybody guide me?
One approach to deal with is to create separate column on your table which will contain popular search tags or keywords, based on that you can show the results to the user.
Synonyms and acronyms are a challenge for information retrieval systems (IR).
Perhaps implement a tiny Acronym Expansion System. Acronyms and expanded terms.
When a user enters such words you need to provide a few suggestions or expanded terms. Like in Google do suggestions or you can show couple of similar terms in return for the query and let the user decide which is relevant.
you need minimum three table as I envisage it but depends on context.
one table contains stop words so you parse each word in the
entered phrase and remove all stop words.
then search individual term in acronyms table and if an
acronym has more than one definitions you can substitute acronym
for each definition and pass it back to user asking which is
relevant. if this is web environment it means list of hyperlinks.
Like a lot of developers who are comfortable with SQL syntax I get frustrated when working with Access's query editor. I'm talking about the raw SQL Syntax view, obviously.
One of its many annoying properties is that upon saving it will discard my layout / formatting. When reopening the query all I see is a bunch of unformatted SQL.
However, if my syntax is long and/or complex enough I've noticed that Access will retain my formatting and layout and, oh joy, the query remains clear and readable. I'm looking at an example right now with a page of SQL containing couple of UNIONs all nicely laid out from a few days ago.
At what point does Access flip over to allowing the user to retain his own formatting? Is it length? Complexity? And is there maybe even a trivial structural edit (if trivial structural isn't an oxymoron) I can make to all my queries which will force Access to leave my layout in place?
There are certain things that Access' query editor is not able to display in design mode.
Queries with UNION are the only thing that come to my mind right now, but there are probably more.
In my experience, Access always changes the layout as long as it's able to display the query in design mode.
As soon as you put something in the query that Access can not display in design mode (like UNION), Access leaves your layout and formatting as it is.
I couldn't figure out why Access kept changing my format in a union query (but not for every query or table included).
I simply created another SELECT query based upon the Union query and corrected everything in design view. It's a lot easier.
When I created the SELET query based upon the UNION query, I included tables or queries that I used as lookup tables and had formatted a field to select the second column from a record in a lookup field that the ubion query had anoyingly converted back to the first field in the selected record (usually the ID No of the record).
For example, I might lookup the account name in a record in the cash disbursements table that should display "Office Supplies Exp" but the Union Query converts at least one of the queries or tables I have combined in the union query to the Account Number, the first record in the lookup table, which was originally hidden in the lookup field.
Just to add to Christian's answer, I've done some more testing and find that UNION and DDL queries are left alone by Access.
If we add Pass through queries to that list, then that would match the queries deemed SQL Specific on the menu:
So, those would seem to be the three special cases.
Before saving just type the word union before the ;.
After opening Access next time, remove the word union and start working. When you want to save, first type union again.
I've been tasked with learning Lotus Domino Designer - not sure what I did in a previous life, but it must have been pretty bad... - and was wondering how to do a lookup on a database to get some values for selections. As this information could potentially be used in a lot of the applications, I'd prefer it only to be in the one place.
I gather I can use #DBColumn, but what happens if an entry in that lookup changes? If the unique value of the lookup is the text, then the relationship would be broken, wouldn't it? Is there any way of mimicing the idea of relational lookups?
I'm assuming I'm looking at Lotus development from the wrong angle, as this seems to be a real limitation of look ups.
I haven't found any decent learning material on the interwebs, so would appreciate any help.
Ta
You would want to store a unique ID along with the textual value in the source database (not unlike what you would do in an RDBMS). Then, only store that ID in any referencing documents, and use a computed-for-display field to lookup the display value. (There is a performance consideration here - and you could "de-normalize" the data and store the ID and text value in the referencing documents, and do some asynchronous work to keep the values in sync - eg: using a scheduled agent that runs every night or every week).
If DB1 has the key values and DB2 has the documents which will reference these values, then in the form in DB2, you would still do a #DbColumn to lookup your value list. In the lookup view in DB1, concat the text value and ID with a pipe separator (textField + "|" + ID) in the first column. That will tell Notes to store only the ID value (what follows the pipe is the "alias" and is what will be stored).
Note: I would avoid using #DocumentUniqueID as the unique ID for these values, as the Document Unique ID will change if the documents are copied and pasted, or the entire database is copied, etc. You can use the #unique formula function in a computed-when-composed field to generate something close to a unique ID (almost like an identity column in sql).
If you need relational properties, look for non-Notes solutions. It is possible to get some relational behavior using document UNIDs and update agents, but it will be harder than with a proper relational backend.
Your specific problem with referencing to a piece of text that might change can to some extent be resolved by using aliases in the choice fields. If a dialog list contains values on the form...
Foo|id1
Bar|id2
...the form will display Foo but the back-end document will store the value id1 - (and this is what you will be able to show in standard views - although xpages could solve that). Using the #DocumentUniqueID for alias can be a good idea under some circumstances.
It depends on where your using the data. The #DBLookup or #DBColumn will work in Lotus Notes fields if the fields are set to be computed for display. That way they always get the most up to date information when you open the form etc.
If you make it so the data is saved on to the document then you will have to write some update code when you need to refresh the values.
The Lotus Notes help files for designer are pretty good, have a look at that.
SM
You could use a key or alias to store the relationship to your lookup value so if the value itself changes, the connection remains because the alias is intact. For example, if your lookup values were being stored as a collection of documents, I'd have the #DBColumn retrieve Document UNID|lookup value pairs. When in display mode, you could then retrive the value using #GetDocField. If the lookup values are in a different database, then you'd have to retrieve them for display using #DBLookup and construct a view that is keyed off of the UNID or whatever key you decide to use.The only drawback to this technique is that you wouldn't be able to display the field value in views as the actual value isn't stored in the document, just a reference to it. Using XPages, though, you COULD map the relationship into a dynamic datatable just like you would in a truly relational system.
It's tricky, but using LEI, you could also use Notes to front-end a relational backend system, also giving you the dynamic relationship you desire in your lookups.
Hope this helps!
The content of the lookup can change freely. A problem only arises (as it would on any other platform in the same circumstances) if the lookup key changes. You need to use a key that won't change. Human-readable text is an advantage, but if you want to be able to change your key description from, say, "Divisions" to "Business Units" and still have lookups work, you need to use an alias of some kind, which will presumably be mapped to your text description and only used internally. #Unique is pretty good for this, and gives a shortish key, if that is important to you. #DocumentUniqueID is most reliable, but as Ed pointed out, will change (must change - it's a new document) if you copy/paste or make a non-replica copy. This is easy to get around, though. Create a Computed-when-composed field (called, say, "LookupRef") on the form you are using for your reference document with the formula "#DocumentUniqueID". That will capture the ID at the time of creation, and it will not change on copy/paste etc. Use that as your key.