Joe Kaufman Bell Laboratories Inc No longer there

Phi,

I got this to work, similar to what Gerardo lists (but does not allow lowercase letters):

^[A-Z0-9\-]{1,100}$

Thanks,

Joe Kaufman

Ron,

Let's try to check the fields next time before they get re-written as properly indexed text. We can grab the text from SQL Server then analyze it character by character in Foxpro to see what the ASCII values are.

If we decide we need to write a scrubber routine we can do that as an automated task...

Thanks,

Joe Kaufman

Great! Now when I forget how it will be on the forums for me to find.  *smile*  The life you support may be your own!

Thanks,

Joe Kaufman

Shimon,

Add indicators for beginning and end of line, otherwise the expression just thinks you are starting a new string on the same line. This seemed to make an online regex checker work better when I tested:

^.{1,18}$

That is, same as before, but with a caret at the front and  dollar sign at the end. That terminates front and back, so something of 0 characters or 19 characters should no longer be considered a match.

If that doesn't work, then yes, I would start to wonder if there is a bug, or if perhaps the regex validator in DW isn't quite standard. All of the other help documentation would indicate that it is.

Thanks,

Joe Kaufman

Shimon,

It look slike the following expression should be close:

.{1,18}

That is, a period, open curly bracket, 1, comma, 18, and closing curly bracket.

The period means any character except line-feed, and the range of numbers in curly brackets means the character can occur that many times (so, effectively a lower and upper bound on length in this scenario).

If the DocuWare help isn't helping, any tutorial on regular expressions should be of assistance. Figuring out regex stuff can be a challenge... Just google for whatever issue you are trying to solve (including keywords "regular expression" or "regex"), and it can help zero in on what you are trying to do.

Thanks,

Joe Kaufman

Seth,

All of my code works against on-premise 6.11.

I don't have anything else to test it on since I am just an end-customer, not a reseller/integrator...

Thanks,

Joe Kaufman

Tim,

I will correct you, then.  *smile*  I just used my code (which uses the same core API method as Seth's code) to staple two documents together directly in a file cabinet -- no tray involved.

I did get two 500 errors, the first because I tried to staple two non-PDF documents together (which apparently throws an error) and then another 500 error when I tried to staple together documents whose IDs did not exist in the file cabinet.

Once I cleared up those error, I got a successfully stapled document, verified in the web client.

I still do not know what a 405 error may indicate. The PDFs I stapled together were in a file cabinet with versioning turned on, and the operation still had no problem once I used the right type of documents (PDF) and used the correct document IDs. My code is below:

=====================

        static public Document MergeDocuments(FileCabinet fileCabinet, List<int> docIds, ContentMergeOperation mergeOp = ContentMergeOperation.Staple)
        {
            // NOTE! This actually merges the documents in the DocuWare file cabinet, meaning a new, merged document
            // is created in the database and the documents that were merged are gone.
            LastError = "";
            if (fileCabinet == null)
            {
                LastError = "Parameter 'fileCabinet' cannot be null.";
                return null;
            }
            if ((docIds == null) || (docIds.Count == 0))
            {
                LastError = "Parameter 'docIDs' cannot be null or of zero count.";
                return null;
            }
            Document mergedDocument = null;
            try
            {
                mergedDocument = fileCabinet.PutToContentMergeOperationRelationForDocument
                    (
                        new ContentMergeOperationInfo()
                        {
                            Documents = docIds,
                            Operation = mergeOp,
                            Force = true
                        }
                    );
            }
            catch (Exception ex)
            {
                LastError = ex.Message;
            }
            return mergedDocument;
        }
 

=====================

As I said, it uses the same core API call Seth is trying to use, "PutToContentMergeOperationRelationForDocument".

Thanks,

Joe Kaufman

Zack,

Interesting software. Sort of kludgey to use and no warnings or confirmations of what exactly is about to get stapled (I just stapled together a bunch of documents and now they are gone -- test data, but still).

But it works. Seth, it worked on a test cabinet I had with versioning turned on. So, perhaps you want to try using it on the file cabinet you are having trouble with, and perhaps it will throw an error that means something more than the 405 error you are getting. Like I said, the software is not very user friendly, but maybe you will find it more intuitive than I did. The 30-day trial is free, so you can at least see if it works against the cabinet you are using.

Other than that, I am not sure why DocuWare cannot provide more information on what the error means. I use similar code and it works for me, so it must be something with the particular file cabinet in play. Without add'l information about the error, though, that is going to be rather difficult to figure out. We shouldn't have to purchase third-party software to use an API call that is clearly documented in the .NET sample code.

Can anyone from DocuWare weigh in on this?

Thanks,

Joe Kaufman

Seth,

Just wanted you to know I am back online here at the DW forums...  Any progress on the stapling issue we discussed on LinkedIn?

Thanks,

Joe Kaufman

Hello,

I am not entirely sure of your question here, but what you are seeing is by design -- all DocuWare date/time fields are stored as UTC values, normalized to a universal time. This makes the data portable (and viewable) across time zones in a way that would not be otherwise possible.

When you view such fields in the web client, they are converted back to your local time zone, as you are seeing.

If you are accessing the data directly from the database, you need to calculate the UTC offset and adjust the date/times yourself if you want to see local time. Most programming environments handle UTC conversions in one way or another these days...

Thanks,

Joe Kaufman