For Tony: any SMO templates

[stanl]

You showed me the light with SQLite saying you just placed my data into an exisiting script you had. By any chance do you have any templates used to test SQL Server with SMO?  or (System.Data.SqlClient).

Stan

[td]

Can't help you there. 

[stanl]

Can't help you there.

Thanks anyway. I'm more comfortable with the general structure of data access with WB's CLR. Most of the C# and PS examples I've seen use ExecuteReader() and GetSchemaTable(). Maybe just .02, but ADO is just soooo much easier to work with and a lot less code to get a desired result. OTOH: the ability to create assemblies/dll's from C# code that WB can use is soooo tempting.

[td]

In general, CLR assemblies are more rigorous and consistent than their COM equivalents.  In some cases, COM Automation is the better choice simply because MSFT hasn't taken the time to do a proper implementation of the managed equivalent. Two notable cases of this are WMI and ADSI. In other cases, a good COM Automation equivalent for CLR functionality either never or no longer exists.  Of course, familiarity can also breed preference. That is human nature.

But we just provide a tool box full of tools. Which tools gets used is up to the user.

[stanl]

But we just provide a tool box full of tools. Which tools gets used is up to the user.

Which tools get used --> glass half empty/half full depending on if the current limitations of WB's CLR are immutable? I'm just a data guy, not that many bells and whistles.

[td]

Which tools get used --> glass half empty/half full depending on if the current limitations of WB's CLR are immutable? I'm just a data guy, not that many bells and whistles.

What limitations exist are well documented and should be considered before using the technology.  There are many, many tasks that the WinBatch CLR does do well but if you find the WinBatch CLR too limited for you then you shouldn't use it. That choice is yours.

I have no idea what you consider bells and whistles but about a quarter of the code in the WinBatch COM subsystem is there to work around inconsistencies and bugs in various specific MSFT and third party COM Automation servers.  The CLR subsystem needs to devote almost no source code to those kinds of issues.  That difference reflects in part the ad hoc nature of COM server development versus the more design driven nature of CLR/managed code development. That difference is also reflected at the script level in subtle and not so subtle ways.