Joe Kaufman Bell Laboratories Inc No longer there

Hey all,

OK, I played around with this, creating a temporary file cabinet, storing documents, then expanding a Text field.

First of all, "expanding the text field" is fairly tricky:

• I did not turn off any services for DocuWare, but I was not performing any administration on the file cabinet in question elsewhere.
• You need to expand the field in the base file cabinet table in the DWDATA database. You may be prevented from doing so due to an option that prevents table changes, so you will need to turn that option off. When I expanded a field, it said it was also modifying the accompanying SECT and VER tables. Not sure why, as they appear to be unchanged.
• You then need to change the "settings" XML field in the DWFileCabinet table (DWSYSTEM database):
• Modifying data in an XML column is a PAIN.
• You need to change the "dwLength" attribute of the UserField in question, and the "length" attribute of the UserField's "DBType" node (sample update queries later).
• All data is preserved; no index values were lost, since this is a same-type field expansion so nothing gets truncated or cast to a different type.

So, that leaves the XML header files stored in the file system. I noticed some interesting things there:

• When I initially store documents to the file cabinet, the length of the Text fields is not defined. The "length" attribute in the XML header file is "-1". (I am not sure if this changes if you have auto-fill indexes or if documents come in via an Import Configuration -- I just brought documents in via a manual Inbox process).
• If you change an index field (any index field) of a document, the user-defined Text fields switch to storing the field length for all of the user-defined index fields. After expanding a Text field, the new (higher) length is stored in the XML header files while all other header files are left alone, either in their initial -1 state or with the previous (lower) field length.

So, older XML header files definitely get out of sync with the newly-expanded structure. I do not know what issues that might cause when trying to recover from some sort of terrible failure where the file system files are all that remain of a file cabinet. But, expanding the field does not seem to be problematic from a DocuWare interface standpoint, and everything seems to work OK after an expansion.

Here is the SQL Server query to change the "dwLength" attribute of the UserField node in question:

UPDATE DWFileCabinet SET
  Settings.modify('replace value of (/FileCabinet/Fields/UserField/@dwLength)[1] with "<expanded value>"')
  WHERE (fid = <key of DWFileCabinet table>) AND (name = <Name of file cabinet, to be doubly sure>)
  AND Settings.value('(/FileCabinet/Fields/UserField/@dbName)[1]', 'varchar(50)') = '<Database name of the expanded field>'

Here is the SQL Server query to change the "length" attribute of the UserField/DBType node in question:

update DWFileCabinet SET
  Settings.modify('replace value of (/FileCabinet/Fields/UserField/DBType/@length)[1] with "<expanded value>"')
  WHERE (fid = <key of DWFileCabinet table>) AND (name = <Name of file cabinet, to be doubly sure>)
  AND Settings.value('(/FileCabinet/Fields/UserField/@dbName)[1]', 'varchar(50)') = '<Database name of the expanded field>'

As Phil says, do this at your own risk! And don't expect to be able to properly restore documents with the now-outdated XML header files should you ever find yourself in such dire straits!

Thanks,
Joe Kaufman
 

Josef,

What becomes of the XML header files? They just start using the new length? If you tried to re-import the raw documents (e.g. to model recovering from catastrophic database failure without backup), would the documents with the old header files import OK? Not sure how much validation DocuWare does when it would try to recover files...

If we had used the field we want to expand in URL integration or API queries I might go for it. But it won't matter so much to us for this particular field. And only about 25 documents have the field populated, meaning we can easily transfer the index data without much trouble. If the latter were not true, that would be another reason to take this novel (but potentially risky) approach.

Thanks,

Joe Kaufman

Jazz,

Is it perhaps related to this?

https://www.docuware.com/forum/english-forums/docuware-help-technical-problems/export-csv-now-exports-semicolon

If you moved to 6.12, that would be my guess -- the delimiter changed, or at least has the potential to change...

Thanks,

Joe Kaufman

True, and unless we know a field is going to be small (like a Yes/No select list, it can't hurt!

Incidentally, we have some a Text field defined as Text 1000 in one of our cabinets (6.11) -- it is structured as nvarchar(1000) in the SQL Server database. So, it sounds like 6.11 can go over 255? It defaults to 255 when you create a new field...

Thanks,

Joe Kaufman

Phil,

Thanks for the response. We probably won't always use max, but will certainly not skimp on it in the future.

Thanks,

Joe Kaufman 

Hey all,

After looking more closely, I see the length of fields is stored in dwsystem.DWFileCabinet.settings as well as every XML file alongside stored PDFs in the file system.

So, it looks like changing even something as simple as Text size would break all existing control files for all documents in the cabinet. The structure itself and the settings field are not a big deal, but affecting all existing stored documents is not something I want to do.

If anyone else has ideas, let me know, but I guess we'll have to do the remove-and-add and try to make plenty of room in fields from the start moving forward.

Thanks,

Joe Kaufman

Hey all,

It seems pretty silly that we can't extend a Text field in DocuWare, that none of the field properties can be changed. I understand not allowing a type change, but extending a string should be legit because SQL Server can handle it with no problem.

Do we really need to remove and add a different field just to expand a Text field, or can I change it in SQL Server and have that work OK? I don't know of any other spot where the data structure is maintained, and the XML contol file doesn't define length, I don't think? Plus, we recently had a field manually added to file cabinet by support to work around an issue we are having with a Task Manager trial expiring. So it seems like the structure defines itself.

Any technical thoughts on this? Can I expand a Text field in the underlying structure and be OK?

Thanks,

Joe Kaufman

Seth,

Same for me, though if we force an Excel instance opem with COM automation, that starts a second process (in fact, we have more issues with processes staying open than the other way around).

I would assume DocuWare shells out to Excel via some sort of COM/interop automation, but maybe not. Might just be a ShellExecute() on the temporary file where the file extension takes over from there.

Does this happen as soon as the Excel file tries to open, or when the user clicks "Save"?

Here is a link to forcing multiple instance of Excel -- might be a workaround, if nothing else?

https://support.microsoft.com/en-us/help/3165211/how-to-force-excel-to-open-in-a-new-instance-by-default

Thanks,

Joe Kaufman

Aren,

ProcessDocumentAction (with the right post data) did the trick? That is great info -- I am going to go look at the documentation on that resource right now...

You mentioned new posts not showing up -- is it possible your account was a trial run (like a cloud demo) and has since expired? If so, you will need to use a different login to be able to post again. The same thing happened to me, and I was told I needed to register with a new email address, and my previous posts could not be linked to the new credentials. You will have to contact DocuWare support for that.

Thanks,

Joe Kaufman

Aren,

I cannot find any respurce with the word "undo" in it, and the .NET library does not seem to have any methods for a Document type that start with "Undo". I hope someone answers this question because I am curious about the answer (though we have no need of it from the Platform Service as of yet...)

Thanks,

Joe Kaufman