Eventargs "do not have a compatible signature”

After pulling a very large solution into smaller projects over the last da or two, a windows forms event handler that used to work, started complaining about the signature not matching for the event. A custom class inherited from EventArgs and added some properties for this event. The definition for the custom event argument resided in one of the class libraries that had been refactored.

To the eye and the intellisense tooltips the signatures looked identical. The break through was found by right clicking on one of the event arguments to “find definition” that lead to the class viewer rather than the code defining the class. This was a clue as this normally only happens when the source is not loaded in the IDE or the project is not holding a project reference, rather a file reference to the .dll of the class library in question.
Furthermore clicking the “find definition” on the other side of the event handler did lead to the source definition for the custom class.

I looked in the class viewer in visual studio and found two identical copies of the class in there. Somehow a cached version of the old .dll pre-refactor was still in the solution. After deleting the /obj and /bin contents for all projects and taking the references out and back in again, it all came back to life as it should.

SQL server truncated data errors

 

“String or binary data would be truncated”, an error raised by SQL server when trying to update or insert data into a column that is bigger than that column can accommodate.

On my wish list for SQL server for a long time has been that this error should provide the column that raised the error as part of the reported error. Our Microsoft ERP system has very wide tables, approximately two hundred columns in some of them. When this error happens, it becomes a pain to track down the failing column update.

The only way I’ve got to do this at the moment is to add the LEN() function around every possible culprit and check the returned lengths manually against the schema. Whilst this works, it takes a long time, just for lack of the column name in the error raised.

eConnect “Customer is Inactive, you must Activate the customer to enter transactions”

Started looking at the eConnect integration with one of our websites today. We get the following error when the customer has been marked as inactive. Inactive in our world is something the finance department quantity, however we obviously want to still accept sales and ask questions later.

The problem is when the customer places the order we get the eConnect error which makes business sense,

WebDocumentTransport.FileProcessingException: Error processing order: 39646 ---> System.Exception: Microsoft.GreatPlains.eConnect.eConnectException: Sql procedure error codes returned: Error Number = 1790 Stored Procedure taSopHdrIvcInsert Error Description = Customer is Inactive, you must Activate the customer to enter transactions Node Identifier Parameters: taSopHdrIvcInsert SOPNUMBE = 3899646 SOPTYPE = 2 Related Error Code Parameters for Node : taSopHdrIvcInsert CUSTNMBR = TEST

 

First I checked to see if there was a field in the XML that overrides this behaviour, there was not so next I thought I could use the econnect pre and post stored procedures to get around this. The procedures, taSopHdrIvcInsertPre and taSopHdrIvcInsertPost, supposedly run before and after the document is processed.

As I was seeking a simple rapid solution, I bunged some TSQL in to stash away the customer status if it was inactive, set customer as active and then restore the status afterwards in the post procedure.

Annoyingly this does not work. The taSopHdrIvcInsertPre never executes if the customer in inactive. I guess the error occurs before econnect hands off to taSopHdrIvcInsertPre. I admit this seems like a acceptable behaviour, just not the one I was seeking.

So looks like I have run the SQL procedures I wrote, before and after the sales document is created myself. Alternatively I have to go back to plan A that was to do the change through eConnect itself that might be the more correct way to handle this anyway.