you are missing SELECT before "substring" .
You had SELECT in your original statement, but somehow dropped it in your last
your statement does not work in MSSQL because there is no such a built-in function "SUBSTRING_INDEX" in MSSQL.
So in your case, just could replace
SUBSTRING_INDEX(name, ':', 1) from mySQL statement
substring(name,1,charindex(':',name,1)-1) in MSSQL statement
Wrong forum for the question.
Here is a statement that will give you result with one minute precision. The number in the field is a number of tenth of microseconds since Jan 1st of year 0001.
If you need more precision, you'd have to try to split the number in two parts and use multiple DATEADDs
(I think your MSSQL needs to be at least 2008 to have datetime2 as available type)
select DATEADD (minute,CONTENTMODDATETIME/60/10000000,convert(datetime2,'0001-01-01')) from FileCabinet_SEC
we found that the only way to prevent some Citrix users from using C2O connection is to uncheck their C2O setting 'Login at Start'. If the user action to uncheck manually is not acceptable, then setting can be changed programmaticly in a C2O configuration xml file located in %userprofile%\AppData\Roaming\Docuware\Connect to Outlook\ folder.
This way only some Citrix users will have C2O connected.
When I start C2O with configuration to monitor a folder, and the folder has few thousands items in it, I get an error 'Out of memory and resources' and the folder is not being processed. This happens to me with DW7.1, Outlook 2016 (tried both 32 and 64-bit)
Before, with DW6.8, C2O could monitor a folder that had several thousand items in it (8K or even 10K items)
This capacity seems to be lost in newer versions.
Has anyone else experienced the same?
Are there any 'tricks' to raise the limit of items in a folder C2O can handle?
a real test would be to look up what you want to search full-text before you store the document in Docuware - using Acrobat Viewer. Then you store the document. After the document is stored and given system sufficient time to run OCR and FT index on the document, perform the fulltext search for the term you found above - prior to accessing the document in any other way.
I did not realize of the 100 pages limit till recently when a customer complained that fulltext searches were not finding everything there was to be found. (And lifting the limit to its max resolved this)
Your testing is tainted by accessing the document prior to performing the FT search - Docuware OCRs and FT-indexes all the pages when the document is accessed.
There is an obscure FC setting (very few of us have ever heard of it) in Docuware Configuration - FileCAbinets - the File Cabinet -General - More Options - Configure fulltext search - Indexed Pages per file. it is set at default of 100 pages
The explanation of this setting is at the following link. I think you need to re-run FT indexing after making the change, so existing documents get processed.
the only time I've seen this happen was caused by some existing Docuware users (including the ones mark inactive) having the same network IDs as users you are trying to bring over from AD.
correct SQL syntax to exclude EMPTYs would be
CustomerNumber is NOT NULL AND CustomerNumber<>'' ----this is not a double quote, but two single quotes
This is equivalent to Docuware search term in CustomerNumber field NOTEMPTY()
the DWDOCIDs do not get changed, but all clipped documents (clipping more than 2 at once is possible) are 'merged' into the first document retaining its docid and all Index values. (All other original documents get deleted) If you want documents be clipped in specified order but retain Index Entries from document other than the top one, you'd need to first collect the index values and , after successful Merge, run posting index values to the Merged document.
I also used a technique to collect particular index value from ALL clipped documents and post the list to a keyword field of the merged document.
What I can't get working is stapling instead of clipping - it gives some 'strange' 405 Method Not Allowed (File cabinets do not support StapleAsync error, though I do not use any Async operations, and all my documents are PDFs. - but there is another post on this issue, incidentally authored by Seth.