Welcome to the Dev-Brothel
About Dev-Brothel PDF Print E-mail
User Rating: / 15
PoorBest 
Written by Administrator   
Thursday, 12 October 2006 10:00

Dev-Brothel is a haven for untrained code whores pimping themselves out for profit (including myself). In addition to keeping a software development and business oriented blog, the site aims to offer some community oriented features such as forums and articles/code for reference purposes.

Last Updated on Thursday, 11 June 2009 15:28
Read more...
 
Gotcha -2146697210 transforming XSL PDF Print E-mail
User Rating: / 3
PoorBest 
Written by Gary   
Thursday, 14 February 2013 19:08

Absolutely no where could I find the answer, but realized it fairly quickly during analysis. While using some older XMLSpy tools (v4) to transform some XML to XSL I kept getting the mystery error -2146697210.

 

I was using files that I knew had worked previously, but the difference was context. I was missing some XSL include files that need to be renamed.

 

Hopefully this note will get indexed and if you get the same error you won't be entirely mystified (of course it may mean something else in another context, I am currently assuming it was thrown by MSXML 4 XSL Processor up to XMLSpy and can't be sure if it is the case that XMLSpy isn't understanding what MSXML is trying to say or if MSXML is just wandering off into the woods with obsure error codes.

Last Updated on Thursday, 14 February 2013 19:14
 
DevXpress Xtra Reports moment of Doh! PDF Print E-mail
User Rating: / 7
PoorBest 
Written by Gary   
Tuesday, 21 September 2010 21:36

While attempting to use the DevExpress XtraReports printBarManager to view a report created in a plugin loaded by a custom plugin architecture I am building I started to get:

 Value cannot be null.
Parameter name: type.

When trying to Create or view the report. Exhaustive google searching didn't turn up this exact error, so I'm adding this entry to share the simple solution (a different error might have gotten me there more quickly, but suffice to say I suspect my plugin architecture may be partly to blame for dodging a compile time error). I needed to include the assemblies as references to my main application so that they would be copied to the application directory and their assemblies could be resolved by the plugin (since no referenced assembly DLLs are copied with the plugin).

At present my architecture only loads the plugin and has no interest in seeking out dependencies (though I may have to add this at some point to the AppDomain.AssemblyResolve handler that currently helps resolve assemblies for NHibernate (since NHibernate won't check a subdirectory for an assembly even if it has been loaded into the application context). The headache is going to be whether to load and check all assemblies in the app directory and the plugins directory or just leave the plugin architecture dependent on assemblies already included in the application (or manually loaded at runtime by the plugin itself). I'd like to keep it simple, but that may not be an option going forward.

 Anyway, babbling now, hopefully if you run into the above error when attempting to XtraRepoert.CreateDocumet() or attempting to assign XtraReport.PrintingSystem to the printBarManager.PrintingSystem property, this will help you track down your error.

Last Updated on Tuesday, 21 September 2010 21:48
 
What a fool I've been... PDF Print E-mail
User Rating: / 2
PoorBest 
Written by Gary   
Friday, 13 August 2010 21:30

Just burned about 20 minutes fighting:

 System.Data.SqlClient.SqlException: String or binary data would be truncated.

in an nHibernate named query. only happened with my CompanyName parameter exceeded an astonishing low threshhold of about 25 characters Was nHibernate getting the two params confused? What was happening?

 Confirmed the parameter lengths were big enough on the sproc I was calling with the named query. Tried using the query-param tag in the named query mapping xml to specify the type as 'string' just in case something mysterious was going on with the nHibernate types on the paramaters. Tried some other shenanigans I can't recall.

Of course I confirmed that the target columns for the param were wide enough in the db. All that checked out, and then finally I found deep in my sproc that I was concatenating the CompanyName param to some other stuff to automagically flesh out an Address Description field which was only 50 characters long.

Bingo, I'm a moron, this concatenation with the sproc was throwing the error. I'm still a little baffled about how to tell exactly where the error is coming from in the nHibernate log, but I will keep my focus on the actual SQL when it is prefixed with  System.Data.SqlClient.SqlException.

 Hope this gives you some ideas of stuff to examine if you are getting the same error, though really if I just would have run the query directly as my first trouble shooting step I would have got through it much quicker.

Last Updated on Friday, 13 August 2010 21:37
 
nhibernate Generic ADO error cannot insert null into column with default PDF Print E-mail
User Rating: / 52
PoorBest 
Written by Gary   
Tuesday, 27 July 2010 21:50

So, I have been attempting to build a Windows Forms application using nHibernate as the data layer. This has been trying to say the least.

Today I encountered a Generic ADO Error "cannot insert null into column <ColumnName>" on a nvarchar column which in deed was NOT NULL, but had a default value assigned in the database. Took a little noodling, and some fruitless google searches, but the solution was in a slight modification to my nHibernate mapping file for that object (I am certain I will find others that require the same tweak, but I'm going to let them break before I find and fix them since the case is somewhat rare).

 If you encounter this issue, just set dynamic-insert="true" on the object map containing the column in question. This forces nHibernate to only reference columns which have values specified in the insert statement. Apparently when nHibernate includes the column and tells MSSQL 2005 to set it to NULL, MSSQL (or perhaps ADO) gets angry inside and decides to cry a river over the seeming mis-step. Exclude the column from the insert (and I highly expect this is an ADO issue) and MSSQL happily uses the default value you have specified for the column without all the tears and yelling.

 I hope if you have this issue you find this post and your own personal Gross National Happiness will be increased for the find and fix...

 

Last Updated on Tuesday, 27 July 2010 22:01
 
« StartPrev12NextEnd »

Page 1 of 2

Polls

I am a...
 

Who's Online

We have 7 guests online