Guido Wieland WIeland Document Solutions & Services GmbH DMS Solution Engineer

Hi Simon,

Thanks for your feedback and yes, sure I get your drift for that matter.

To cover for mentioned eventualities it would definitely be advised to go for an explizit CAST or CONVERT.

Nevertheless, presuming mentioned implicit conversion is and remains supported by vendor, in such case the outlined example would indeed work just fine as long as DW_ID_LONG contains only integer values, correct?

Best regards

Guido

Dear Community

I have the following scenario or SQL query in a workflow data assignment:
 
SELECT [title] FROM [RV - system data] WHERE DW_ID_LONG = GV_Standard_Aufwandkonto_Nr
 
Variables/-types used:

Database field => DW_ID_LONG = Text (NVARCHAR(12))
Global workflow variable => GV_Standard_Aufwandkonto_Nr = Numeric
 
From an SQL perspective, the following applies in principle:

Generally MSSQL will transfer data from a varchar field to an INT (numeric field) as an implicit conversion - meaning that you do not need to specify a conversion. You will however need to pay careful attention to decimal places if you use an INT (numeric field).
(From <https://support.docuware.com/en-US/forums/help-with-technical-problems/c3e2967b-2d36-ea11-8454-0003ff59ab14>)
 
Accordingly, and assuming that the database field DW_ID_LONG only contains integer values in the range of -2147483648 and 2147483648, I believe that in the case of a pure WHERE comparison, no explicit data type conversion (e.g. using CAST (DW_ID_LONG as INT)) is necessary and the two variables can be compared directly with each other despite natively different data types.

Basically, the whole thing seems to work, but due to internal discussions with colleagues, opinions differ and I would like to ask for opinions and/or experiences from the community.

Best regards
Guido

Dear Community

I have the following scenario or SQL query in a workflow data assignment:
 
SELECT [title] FROM [RV - system data] WHERE DW_ID_LONG = GV_Standard_Aufwandkonto_Nr
 
Variables/types used:

Database field => DW_ID_LONG = Text or NVARCHAR(12)
Global workflow variable => GV_Standard_Aufwandkonto_Nr = Numeric
 
From an SQL perspective, the following applies in principle:

Generally MSSQL will transfer data from a varchar field to an INT (numeric field) as an implicit conversion - meaning that you do not need to specify a conversion. You will however need to pay careful attention to decimal places if you use an INT (numeric field).
(From <https://support.docuware.com/en-US/forums/help-with-technical-problems/c3e2967b-2d36-ea11-8454-0003ff59ab14>)
 
Accordingly, and assuming that the database field DW_ID_LONG only contains integer values in the range of -2147483648 and 2147483648, I believe that in the case of a pure WHERE comparison, no explicit data type conversion (e.g. using CAST (DW_ID_LONG as INT)) is necessary and the two variables can be compared directly with each other despite natively different data types.

Basically, the whole thing seems to work, but due to internal discussions with colleagues, opinions differ and I would like to ask for opinions and/or experiences from the community.

Best regards
Guido

Hallo zusammen

@ Tobias Getz @Roger Goetzendorff Besten Dank für eure Inputs, denke beides durchaus valable Workarounds.

Zumal ich die eigentlichen Stichwörter für die Weiterverarbeitung jedoch möglichst in ihrer "originalen" Form benötige erscheint mir der Ansatz mit der einspaltigen Tabelle aktuell die zielführendste Option zu sein. Versuche mich mal in diese Richtung und melde mich wieder ;-)

Beste Grüsse

Guido

Hallo

Wie bekomme ich es hin ein Stichwortfeld ähnlich einem Array mit mehreren, IDENTISCHEN Stichwörter zu belegen, also z.B. Stichwortfeld = Hans, Peter, Sandra, Hans, Sandra etc. bzw. ist dies mit diesem Feldtyp überhaupt möglich?

Beste Grüsse
Guido Wieland

Hi there, pretty much same issue here. With most of our customers being hooked up with Docuware Cloud, we likewise do not proactively monitor their local (server) setup serving the Desktop Apps functionalities. Accordingly we usually only get to know when LDC stops working whenever some Autoindex and/or Workflow synced data does not reflect in customers' Docuware. And like in Daryl's case, particular LDC outages always seem to coincides with pending (intermediate) Desktop App updates.<br> <br> While running silent update as suggested by Craig could be a way to go in case of a major 7.x update (requiring to get the particular installer preped on the respective system), this would be pretty much of an overkill in case of some pending minor 7.x.x.xxxxx update.<br> <br> Until the issue has been taken care by Docuware, since LDC does provide logging details (in %ProgramData%\DocuWare\Logs) we are currently contemplating some sort of proactive monitoring of respective logs and related entries in the servers' eventlogs, hopefully putting us in a position to react ahead of any customer troubles/complaints.<br> <br> For the time being, any other suggestions how this matter could be addressed with the least possible effort for us as and disruption of customer?

Hallo

Nicht sicher,ob sich zwischenzeitlich etwas in dieser Sache bewegt hat, zumindest habe ich in der aktuellen 7.5er Version keine offensichliche Möglichkeit dazu gefunden.

Stehe aber an genau derselbe Stelle wie schon Frank vor einem Jahr ... "Somit muß ich Freigegebene Postfächer zurückverwandeln, dem Benutzer ein festes Passwort vergeben und eine Exchange-CAL dafür verbraten."

Wenn immer noch nicht direkt in DW, gibt es ggfs. eine andere Möglichkeit/Workaround ein freigegebes Postfach anzubinden?