As per IBM's APAR IV71868
There is a new property - si.device.createdLocallyLimit in worklight.properties that manages the maximum of workorders kept by on the device. By default it's set to 10. Once you get past that count, the workorders will be removed automatically from the device.
What is the criteria for removing these workorders? Is it on internal row id in the local database or is it based on a sort order?
e.g. If I create workorder ce-101123 which comes after workorder ce-9834. But if the removal works based on wonum then ce-101123 will be removed instead of ce-9834 as that will be sorted alphabetically?
It looks to be based on how you sort the order, but you could modify the _updateCreatedLocally function found in _ServerDataDownloadManager.js to do a sort on the store based on some criteria before it starts the remove process.
Related
I'm working with a client on obtaining Bills and Adjustments values through the Contract based web services. I understand that certain fields aren't available in the Default Endpoint, and have to be obtained through an extension.
I'm trying to add fields from the Bills and Adjustments' Applications tab, but I'm running into a warning that I don't understand. If I extend the Default endpoint for 'Bills' (call it 'BillExt'), and I try to add the Reference Number field from the 'Applications' tab/grid (or any other field from that grid) - I get the following warning (see screenshot below)...
Can someone explain what the issue is, and how I go about adding these fields from the 'Applictaions' tab/grid? I've added fields from the 'Approval Details' grid without this warning without a problem. Is this a warning I can disregard?
You are trying to add a field from another table/view that can return multiple rows for a single Bill.
The correct way to do this is by adding a separate collection on the object and map the view on that collection. e.g: Applications or Details collections here.
That collection will have the information for all records related to the header once you retrieve them using the ?$expand=Details on the query string request.
This issue brothers me for a long time.
I have two environments. 1 for development, 1 for production.
I did the same steps as below:
1, Create a new customer named "TESTID"
2, Delete the "TESTID" after creation immediately. At this time, it would be marked deleteddatabaserecord =1 in BAccount table.
Now, here comes huge different. If I recreated the "TESTID" in my development environment, the system allows and just update the deleteddatabaserecord to 0 and other fields updated according to new input. However, the production environment won't allow to created the customer "TESTID", says "Can not insert duplicated line into object "dbo.BAccount" with unique index. The duplicated key is (2,TESTID)"
This issue also happens to other entities, such as Stock Item. So is there a switch or specific setting?I would be really appreciated if somebody could give me the right direction.
The error says you can't insert entity into the table because of unique index constraint. And you don't have such error in another environment. I'd started investigating from checking if indexes are the same for dbo.BAccount table in either of the environments.
I'm trying to figure out how ExpressionEngine deletes entries.
I've written an log-like extension that tracks when an entry is created. When I delete an entry through EE's edit section, the entry is also removed from the separate table I created for my extension.
How does EE know to delete the row from my table when the entry is removed? One of the columns in my table is `entry_id`. It would seem like EE automatically checks all tables for a entry_id column and if the value matches the value being deleted, the row is removed. Can anyone confirm this?
It would explain why I didn't have to make a function that hooks into delete_entries_loop to achieve this functionality.
That's very odd. That behavior would be insane if it was indeed the case!
Looking at the delete_entry() method of the Channel Entries API, the deletions are very specifically limited to:
channel_titles
channel_data
category_posts
relationships
comments
comment_subscriptions
channel_entries_autosave
entry_versioning
The Channel Fields API is also called, to let fieldtypes delete what they need to from their own database tables based on the entry being deleted, but only if they contain a delete() method.
I'd suggest turning on the output profiler, then running the deletion routine to see what queries are being run.
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!
For the documents stored in the database, I would like to create a human readable key to uniquely identify the document. e.g. PO20090110-001. How do I go about doing that?
When saving a document you can put together the first part of the number by using the date or any technique you like (ej. "PO" & format(date, "YYYYMMDD") & confDoc.getitemvalue("doccounter")).
As for the counter I like to store it in a configuration document and update it when each doc is saved. If there are lots of documents created during the day you can run into rep conflicts on you configuration document, if this is the case you can have an agent on the server do the actual assigning of the number, the drawback to this is that you don't get the number right away when saving.
Hope this helps.
One solution used in our help desk is to take the initials of the current user and add it to the a number in the last document in a view. Add one to the number and store that it the new document along with the ititals and the new number as the key.
It's not simply.
Create field for uniquely key and this key saving onSave (or other event), but you must protect this number to be unique.
You can create agent, which checking number on domino server and if agent find conflict then notify application administrator or other responsibility person to resolve this.
Or each replica generate own number and after replicate on domino, agent assign number in right format.
You can create a "nearly" unique key in Domino simply by using the #Unique function, with no arguments. This will generate a string key, based on the current user's first and last name and the current clock time. You will end up with a string something like: "ESCR-12345678".
I say "nearly" unique, because it is not really like an identity column in SQL - Domino does not guarantee it will only give out a particular string once. If you use #unique in a server-side agent which generates many id's at once - for example, and agent that loops and uses #unique within the loop, you can get into a situation where #unique will return a duplicate - because you create 2 docs within the same second and because your "username" is always the server's canonical name. But, outside of that scenario, #unique is generally safe to use.
If you then need to open or reference docs by this ID, just create a view sorted by that ID and you can a url in the form ../myView/id?readDocument.