The amount of time that this cost me is astounding for such a stupid issue. (And, I’m going to lay the blame fully on whoever wrote the dbRoot object in the MyGeneration project. Total improper use of properties).
The situation was this: I was trying to dynamically wire up all the plumbing that the mygeneration windows app does for you manually from the ZeusCmd command line.
Doing this would allow me to switch from DB to DB within my code gen application.
Because ZeusCmd runs first (it references my app and passes in what is needed), if you had previously saved a connection in your MyGeneration app, then this connection is used when ZeusCmd runs. I didn’t want this to happen because as I move from location to location different DB servers are available or not available, so if the last DB server I connected to was at office A, I didn’t want my code gen crashing onload when I am out of said office.
So I ran MyGeneration and changed my connection to be <None> and saved the settings. Then in my code gen, I tried to manually create the dbRoot object (named meta here) that was previously created for me my ZeusCmd and my saved MyGeneration settings.
Code like this:
meta.Connect("SQL", "Provider=SQLNCLI;Server=cmayt61p;Database=DBName;Trusted_Connection=yes;")
Seemed to do the trick.
However, my codegen started blowing up on my later in the process. After tracking down the error I find that the mygeneration result column object can’t figure out the .net type that would be the same as a sql server “int”. Strange, never had these problems before.
A lot of debugging leads me to find that:
meta.DbTarget
meta.Language
Are both returning “” when before they were returning “SqlClient” and “VB.NET” when I was not dynamically connecting.
So here is where things get bad… anytime I try setting these properties to their values:
meta.DbTarget = "SqlClient"
meta.Language = "VB.NET"
Nothing happens. The values don’t appear to stick.
Eventually I even start trying to set the LanguageMappingFileName and DbTargetMappingFileName properties as well:
meta.DbTarget = "SqlClient"
meta.Language = "VB.NET"
meta.LanguageMappingFileName = "C:Program FilesMyGeneration13SettingsLanguages.xml"
meta.DbTargetMappingFileName = "C:Program FilesMyGeneration13SettingsDbTargets.xml"
I tried doing these property sets before connecting and after connecting.
I tried returning to having MyGeneration setup the meta object form me (and all these properties have their values) before dynamically connecting (and losing the DbTarget and Language property values).
I even tried creating a brand new dbRoot object, as well as trying to read some hidden values in the IZeusInput object.
But, in the end, it all came down to the this 1 little thing:
You have to set the mapping file properties before you can set the DbTarget and Language properties.
So this will work just fine:
meta.Connect("SQL", "Provider=SQLNCLI;Server=cmayt61p;Database=MSiUpgraded;Trusted_Connection=yes;")
meta.LanguageMappingFileName = "C:Program FilesMyGeneration13SettingsLanguages.xml"
meta.DbTargetMappingFileName = "C:Program FilesMyGeneration13SettingsDbTargets.xml"
meta.DbTarget = "SqlClient"
meta.Language = "VB.NET"
But this won’t:
meta.Connect("SQL", "Provider=SQLNCLI;Server=cmayt61p;Database=MSiUpgraded;Trusted_Connection=yes;")
meta.DbTarget = "SqlClient"
meta.Language = "VB.NET"
meta.LanguageMappingFileName = "C:Program FilesMyGeneration13SettingsLanguages.xml"
meta.DbTargetMappingFileName = "C:Program FilesMyGeneration13SettingsDbTargets.xml"
It just so happened that everywhere that I was testing this stuff in my code, I always set the DbTarget and Language properties first, and they would never stick.
This is not a proper use of properties. If a property set has conditional logic that will prevent it from setting, there is something wrong here. At minimum something should happen, an exception being thrown maybe? The proper thing to do in my mind would be to make DbTarget and Language readonly properties and have functions to set their value, which could return something indicating failure (or throw an exception).
Property gets and sets should do just that, get and set properties. There shouldn’t be logic in there deciding if and when to actually perform the set that you have coded. That is the job of a function.
UPDATE: And I discovered as well that you have to connect first before you set any of these values, or none of them will stick. So you have to 1) connect 2) set the file paths 3) set the language and dbtargets, in that order or nothing works.
Login in to windows (need admin pw)
Chris May 