I have the following two lines of code:
Set customerView = db.GetView ("(Lookup - Customers by Reference)")
Call customerView.refresh()
Very occasionally, the 2nd line will give users an Error 4000, Query is not understandable
Restarting Notes gets rid of it, but it sometimes comes back for a couple of users.
This has only recently started happening, and I've not made any changes to the view.
EDIT
To explain further, nowhere in the function that is throwing the error is there any code relating to a FT Search, which makes me think that this may be an error that IBM have stuffed up in R9.0.1
Check Forms and Fields (especialy fields!) you use in search formula of the view.
Maybe you search text value in non-text fields.
Fields are shared between forms, i.e field is unique not within form, field is unique within NSF. So, first time you create field - NSF writes it's properties (field type included) in NSF structure. And if you have two forms containing field with same name, but with different types (text and non-text) - you'll get this error.
I saw this error several times, and every time it was caused by FT-queries or search formulas what tries to search some text value in field, that initialy was created as non-text (date or numbers field).
If this is the case... Well, it's hard to get rid of this error. Basically you'll have to delete this field from every form and every document in nsf, then compact it using copy-style, then recreate field in right type and restore it's values in docs using right type - it helps usually.
Related
Sorry this isn't a specific coding question, it is more of a design concept.
What is the usage case for programmatically adding and removing fields to Notes Forms e.g. NotesDocument.RemoveItem(), ie why would you add and remove fields in the background?
For many years I have designed my forms with the fields layed out on the form which are required and then hide and show as required.
By adding dynamically you can't position them and frustratingly removing them or deleting they still appear the Database Fields in Domino Designer, getting rid of them is a bit a a black art, but that's another story.
I must be missing a trick or a basic design concept. Any thoughts on best practice would be appreciated.
Many thanks.
Yes, you are missing the difference between "Fields" and "Items". A field is a design element that you can place anywhere on your form. You define how it looks, what content it contains, what datatype it is, etc.
When creating a document with the form the value of the FIELD is stored in an ITEM in the resulting NotesDocument.
This item is totally decoupled from the field that created it. If you were to change the field in the form from text to number or move it around or make a names- field of it, the item in the existing documents would never change unless you open the documents and save them in frontend or use any LotusScript or Formula Code to recalculate the document in backend.
Very often items are added programmatically to documents to fulfill different purposes: Calculate values to be displayed in views, calculate values that are import for the workflow but not for the user, etc.
Complex applications often consist of a lot more items than there are fields in the several forms.
Back to your question: Removing an item from a document simply removes the value that was created by the field in the form. When reopening the document, the item will be repopulated, either by default value or whatever....
Usually you would use this to remove items that you no longer need (and probably already removed from the form).
As soon as you removed all references to a field / item everywhere in design and documents, you can finally get rid of it completely by compacting the database.
An item is distinct from a field in Notes. The form is purely a UI concept, the item is what the data is stored in.
Manipulating data in the backend can be used for a number of reasons. One such use case is the setting of a flag when a date on the form has expired.
Say you want a view showing all documents that have expired. Your rules dictate that documents are considered as "Expired" after 7 days. You could create a view with a formula that shows all document whose date is 7 days older than today:
SELECT Date < #Adjust(#Today; 0; 0; -7; 0; 0; 0);
This view will ALWAYS be out of date and will constantly be updated by the server as it re-evaluates #Today.
Now, a better way would be to create an agent that runs daily that sets an item on the document to indicate that it has expired e.g.
#SetField("Expired"; 1);
The view formula would then be
SELECT Expired = 1
The view would only need to update daily and you have a much faster view because of it.
RemoveItem is used to get rid of data no longer needed e.g. FaxNumber.
There are many use cases for RemoveItem. Here's one that comes up frequently.
You have a database and an agent that processes documents in that database. Every time it runs, the agent replaces the value of a bunch of items. There are a variety of error conditions that can cause it to abort processing a document early, but you're a smart programmer and you've accounted for that with on error traps. When you hit one, you log an error message, save your document, and then either abort your agent or go on to processing the next document.
But at this point, some of the items that the agent normally updates have values saved from this run, and some of them have values saved from a previous run. This might be bad. This might be confusing for someone who is looking at the item values and trying to figure out what's going on. This might even cause validation errors on the form.
So how do you avoid this? At the very beginning of your agent, you call a cleanup sub that finds and removes all the items that the agent is going to update. Now you have a clean slate, and if your agent hits that error condition, it can save whatever it can save without any concern about whether it is leaving things in an inconsistent state. Of course, in cases where you are doing this to avoid validation errors, your validation formulas will have to be smart enough to be checking #IsAvailable for dependent items, but that's a good practice anyhow.
I have an xPage that is behaving very oddly. (if xPages get corrupt, I think this one might be) Tell me what you think:
I have editable fields with onChange events that take the value of the field (a company name) and looks into the database to see if the company already exists. If it does not, a field called "isNew" is set to "y". BUT the next time a Full Update is performed, from another field or button, my "isNew" field (or all of them) are erased! Why on earth would a full update erase a totally different field?
Do I need to just recreate this xPage?
============================================================================
Ok, here's the onChange event on the editable field that sets the flag:
var c = currentDocument.getItemValueString("company");
var id = #DbLookup("","AD",tc,11); // this view column gets the doc ID
if (id==null || id==""){
#SetField("isNew","y")
}
This field is being set properly - I use a computed field to display it. But the next full update (button, field, whatever) will erase the "isNew" field.
I think your problem is caused by the data sources you have on your page and how you save them.
Maybe you have data sources that gets binded from the url that should not be.
Are you using data sources within a repeat or view panel? If so, make sure you are only saving the correct data source
JSF (and thus XPages) works best when keeping MVC in mind. So you never manipulate a component, but keep that component bound to a model, like a data source or a scope. This way code doesn't get into each other's way.
A refresh of a page computes the whole tree, not just the updated field, so you need to design your calls carefully.
Work directly with your data source so do this instead of #SetField():
currentDocument.setValue("isNew", "y")
I am new to stackoverflow because I almost never ask questions in forums as there are plenty of questions out there already answered. However my head is about to explode from trying to figure out how to do this app.
First I do this using XCode 4.5.2 for OSX 10.8 deployment of a personal (that is for my use only) double entry accounting software.
Each accounting entry consists of a header of various text fields such as the entry date, a serial number, etc. which I created an Entity called "Entry". Also each such entry has multiple lines such as the various accounts related to that entry, amounts, etc. called an Entity "EntryLine" linked in the model nice and easy.
The thing is that I intended to use text field for the basic header info and below it a linked Table View for each of the line. Being an accounting software there are several checks (validations) that I need to make and I need full control of what is going on. Already tried binding two array controllers, one for each entity and linking the two and saving them to the sqlite file but to no avail!
Now I have an app with just the header up and running by manually getting and setting the info in the top text fields as I please and saving them to the file. But I have no idea how to do the part with the Entry Lines in the Table view. Can I do that manually too or is it better to do bindings through an array controller?
Also tried already with array controller but I get "Table View Cell" when I add a new line in the table. Any ideas on that?
In the Table View there is also an "Account Name" part that is NOT part of the EntryLine entity but my intention is to obtain this information from another entity called "Account" that stores the Account Number and Account Name. On input of the account number that is, the app would skip the name field and move to particulars for input but also bring up the name of the account already inputted. Is this even possible?
Sorry for being a bit vague in my questions but I come from routine program oriented languages and not object oriented one, though I have some Java experience. Any help would be appreciated. No screenshot sorry as I am not yet allowed:(
Using Lotus Notes designer I have created a form and added a field on that form that does a #DBColumn look up. The form then is viewed through the web browser and everything worked great.
I proceed to add another document to the database using that form, now the original documents still render in the browser fine but the new document doesn't return anything to the field.
I tried removing the #DBColumn look up and just displaying text but nothing I just get 0.
The weird thing is if I rename the field to something diferent everything works perfectly but then if I rename the field back, broken, no calculation.
Does anyone know why this is? It has happened to me with various fields through out my application. I originally thought maybe it was a reserved word thing but I now know that is not the case. I usually just rename the field and move on but there has to be an explanation. Is it a caching thing or what?
Thanks for the info!
You haven't mentioned the type of your fields Is it 'computed for display'? If you have computed for display fields in a form, and the documents already contain data stored in an item with the same name, then the computed formula is bypassed and the item value is displayed as-is.
Fields not calculating could be a caching issue. Try opening the form, edit mode, F9 to recalculate all fields.
If this does not help, close the form, press Ctrl+Shift+F9 to forcefully refresh all views in the DB (could take some time). Reopen your form, edit mode, F9. If the value shows up, try using the "nocache" parameter on your #DBColumn.
Depending on your application design, there could be a number of reasons for the problem. Perhaps the view used for lookup is not set to autorefresh or the server does not refresh often enough because of high load issues.
I'm currently writing an application that moves Notes documents between databases based on the amount of days that have elapsed from the creation/modified/last accessed dates. I would just like to get ideas on a simple and convenient way to create documents with specific dates, without having to change the time on the Domino server, so that I could test out my application.
The best way I found so far was to create a local replica and change the system clock to the date I want. Unfortunately there are problems associated with this method. It does not work on the modified date - I'm not sure how it is getting the modified date information when the location is set to Island (Disconnected) - and it also changes the modified and last accessed dates when the documents are replicated to the server replica.
Someone suggested trying to create a DXL of the document, modify the date time in the DXL file, then import it back into the database as a Notes document; but that does not work. It just takes on the date-time that it was created.
Can anyone offer any other suggestions?
You can set the created date for a document by setting the UNID (which is fundamentally a struct of timestamps, although the actual implementation has changed in recent versions). Accessed and modified times, though, would be unsettable from within the Notes/Domino environment, since the changes you make would be overwritten by the process of saving the changes. If you have a flair for adventure and a need to run with scissors, you could make the changes in the database file itself either programmatically from an external application, or manually with a hex editor. (Editing the binary will work -- folks have been using hex editors to clear the "hide design" flag safely for years. Keep in mind that signed docs will blow up badly, and that you need to ensure that local encryption is off for the database file.)
There's actually a very simple way to spoof the creation date/time: just add a field called $Created with whatever date/time you want. This is alluded to in the Notes C API header file nsfdata.h:
Time/dates associated with notes:
OID.Note Can be Timedate when the note was created
(but not guaranteed to be - look for $CREATED
item first for note creation time)
Obtained by NSFNoteGetInfo(_NOTE_OID) or
OID in SEARCH_MATCH.
Unfortunately, there's no analogous technique for spoofing the mod or access dates. At least none that's ever been documented, as far as I know.
I imagine given how dependent Lotus Notes is on timestamps (for replication, mainly), there isn't an API call that allows you to change the modified, created, or last access dates of a note. (More on the internals of Lotus Notes can be found here.)
I dug around the Notes C API documentation, and found only one mention on how to get/set information in the note's header, including the modified date. However, the documentation states that when you try to update that note (i.e. write it to disk), the last modified date will be overwritten with the date/time it is written to disk.
As an alternative, I would suggest creating your own set of date items within the documents that only you control, for example MyCreated, MyModified, and MyAccessed, and reference those in your code that moves documents based on dates. You would then be able to change these dates as easily as changing any other document item (via agents, forms, etc.)
For MyCreated, create a hidden calculated form field with the formula of #CREATED or #NOW. Set the type to computed when composed.
For MyModified, create a hidden calculated form field with the formula #NOW, and set the type to computed.
MyAccessed gets a bit tricky. If you can do without it, I suggest you live work with just the MyCreated and MyModified. If you need it, you should be able to manage it by setting a field value within the QueryOpen or PostOpen events. Problems occur if your users have only read access to a document - the code to update the MyAccessed field won't be able to store that value.
Hope this helps!