I do not think this can be achieved as a proper solution. First of all, Stamps do not support multicolumn select lists, and even though SQL statemetns are allowed in on-premise systems, usage of system fields like DWDOCID or even CURRENTUSERLONGNAME() is not possible,.
BUT... if you have an on-premise system and not a large number of users that stamp documents at the same time, I may have a workaround for you. I've done something similar to this in 6.12 - not sure if would work in DW7 though.
John, if your document is stored with the decimal field equal 0 (or 0.00) then you may seach for it by placing 0 in start range and another 0 in the end range of your decimal field in the search dialog.
BUT, if your field is stored without any value (NULL in database), you cannot search for it by using a search dialog. But if you have Tasklist module, you can create a list and specify filter criteria as Decimal Field = "is empty" - this will show you only entries entered as NULL.. If you want your result also to include 0 amounts, use this filter criteria in your list definition: DecimalField = "Is (where claus)"=EMPTY() OR 0
John, if you have DW Premise AND are familar with MSQQL data manipiulation, below is a way to reset Automatyic Numbering, otherwise your only choice is to create a different numbering group and re-assign it to all dialogs as required.
Here is how you change Automatic numbering in MSSQL:
1. Find out the value of the Automatic NumberingGroup SettingID - this is column setid in table dwsystem.dbo.DWFCSettings - just search the table for name=yourAutoNumberingGroup name and find out corresponding setid
2, Search table dwsystem.dbo.DWSequence for column settingsid=setid found in step1 and change value of column nextNumber for the row.to a desired number
That will reset the next number.
Seth, I have exactly the same need and seemingly the same configuration as your screenshot - and it is working for me. If you are getting empty result list for the related documents, I'd check your data : is the value of the field exacly the same in both places? check for extra trailing spaces. I suggest you search for an invoice, do 'Edit Index Entries' and from that dialog copy value of the Assets# text filed and then paste it into the Assets# keyword field of the search dialog for another fFCand see if it finds anything.This should produce the same result as your relation link.
Again, exactly the same configuration works for me.
I have seen exactly the same issue. It turned out to be that a dash (or minus sign) character - ASCII code 0x2D, was recognized as character that looks exactly the same, but has a hex value of 0x1020 -from a different language code page. Causing searches not finding these entries.
We could not find the root of the problem, so we just opted for a sql script that replaces 0x1020 character with 0x2D in all index entries where it finds it.
Have not seen this thread till today. Here is a sample AIX job - also works in the cloud to accomplish the task. (Sample FC, Document Pool, keyword name = catchword is used as an example)
Make sure you create a numeric indexfield (let's say named 'NumberofKeywords'). Create a scheduled AIX job on sample FC, with the MAtchData tab configured as follows:use extermnal database, use GUID_autoindex dataabse connection - following SQL statement :
"select dwdocid, count(*) as NumberofEntries from document_catchword group by dwdocid"
On Assign Data tab select
Field NumberofKeywords=Field, NumberOfEntries
Schedule the job to run as often as you need.
If you have AutoIndex module and on-premise system, same method can be used, just use Content database connection for external database
thank you very much for going out of your way for testing this.
Does anyone know if using NodeJS Validation with Store dialog used in Docwuare form submission, produces the same result as using the store dialog, In other words would it pass the error mewssage to the submitter of the form? What if public user is used to submit the form?
thank you for pointing this out to me. I got confused by the new name being Doc ID instead of DWDOCID.
Original message removed - as it was incorrect and misleading.
See Phil's reply.