September 2003 - Posts
Why the HELL does sql server 7 wreck the execution plan compared to regular sql queries? My raw sql works perfectly within a time span of 5 sec whereas the sproc measures more than 2 minutes? I tried defaulting params so the huge table scan as shown by the execution plan uses index seek instead. Also I tried these google tips but that wouldn’t solve my problems either. Any ideas?
Some SQL goodies:
SELECT CustName
FROM Customers
WHERE CustID = 10
CREATE PROC FetchBogusCustomer(
@ID int)
AS
SELECT CustName
FROM Customers
WHERE CustID = @ID
GO
I achieved certification for ISA S88.01 “The industrial standard for Flexible Manufacturing and Batch Control systems“. Last week I’ve been at TWP’s boot camp lead by Bianca Scholten. Next up is S95… The S95 Standard for Enterprise Control System Integration defines interfaces between application at the Industrial Control Level and application at the MES (Manufacturing Execution Systems) Level. As such, it bridges the gap between control level communications which are typically implanted using OPC, and business level application using EDI and various B2B standards. The first official part of the S95 standard is defined by ANSI / ISA - 95.00.01-2000.
Sounds interesting right? I started the process of engineering a framework based upon these standards. Really cool stuff because the actual implementation leans against XML and the latest communication protocols.
I lately noticed I’m losing my touch. What the exact reason is?!? I have no clue but one thing I do know is that my work situation isn’t perfect but almost excellent. My personal situation isn’t perfect but almost excellent… read more here.
Exception granulation? How far do you go while handling expected and/or unexpected exceptions? I’m just curious.
public override AbstractDomainEntity DoLazyLoad(AbstractDomainEntity obj, DataRow dr)
{
try
{
base.DoLazyLoad(obj, dr);
((SupplyBatch)obj).SupplyInfo = new SupplyInfoMapper().FindForBatch((Batch)obj);
foreach(SupplyInfo si in ((SupplyBatch)obj).SupplyInfo)
{
Trace.WriteLine(Component.MyFramework, LogEntryType.Debug, "Hooked SupplyInfo entity" + si.OID.Value + " to Batch entity: " + ((SupplyBatch)obj).OID.Value);
}
}
// Raised due to invalid data.
catch (InvalidCastException ex)
{
throw new NotImplementedException();
}
// Raised due to faulty attribute mapping.
catch (ArgumentException ex)
{
throw new NotImplementedException();
}
// Raised due to <null> data.
catch (ArgumentNullException ex)
{
throw new NotImplementedException();
}
// FindForBatch raised...
catch (SupplyInfoNotFoundException ex)
{
throw new NotImplementedException();
}
// Bubble unexpected exceptions to caller.
catch
{
throw;
}
return obj;
}
Lately we’ve been re-developing our logging implementation. Basically it comes down to defining a decent interface and implement a component running as a windows service so clients can publish debug and trace information via the push model. One of our main goals is to make a stop to add-hoc logging in files and dumps to the event log. Heck some service engineers didn’t even know the existence of DbMon.exe what basically means nobody ever seriously investigated the art of instrumenting applications.
Where does this all leave me with System.Diagnostics on my shelve? I’m about the only one doing .NET around here!
We decided to craft a VB6 windows service registering itself in the ROT capable of receiving file events. This due to the fact changes to the configuration file (which is XML actually) shouldn’t go un-notified. We don’t want to stop the execution of our main framework in order to reload the configuration (obviously). We now can configure every single component to log to DbMon, event, file, mail whatever with separate categories like information, system error, application error, database error, warning, debug.
This made me decide to skip the Diagnostics API that .NET provides and just interop with the VB6 ActiveX. The trick here is to make sure we’ll receive the unique instance as registered in the ROT. It took some time to figure out that:
LoggingManagerC.cLomCRootClass lmc = (LoggingManagerC.cLomCRootClass) GetObject("","LoggingManagerC.cLomCRoot");
creates a new instance. This did the trick:
LoggingManagerC.cLomCRoot objLoggingService = (LoggingManagerC.cLomCRoot) Marshal.GetActiveObject("LoggingManagerC.cLomCRoot");
I’m now really enthusiastic about .NET’s interoperability. One step further on the path towards .NET acceptance amongst the members of our management team. Is it? Well argh you just never know when it’ll hit them.
Why I code Rory and DonXML?
I’ve been spending a large part of my life studying technical stuff and maintaining machinery, getting dirty hands so to speak. Me in my blue overall and tools, fixing stuff, building stuff and accidentally break stuff ;) On numerous occasions I met service people who where practicing maintenance on milling machines. Those beasts where running on industrial Unix variants communicating via FTP with AutoCAD modules which where producing machine instructions from drawings. Then it struck me… I needed a career change, I needed to stop thinking from nine to five, I needed to spread my wings… I decided to become (at the age of 21) “yet another geek”.
I went back to the University and got the needed papers, started the company Connexx Communications within a partnership and learned, learned… even more. Recently started working for KSE and OAEurope writing industrial automation software. After 5 years of hard work on my career change I dare to say “I certainly know my stuff, but there’s still a hell of a lot to learn from you”.
Can someone who read both books explain me what exactly the difference are between these two titles? The MCAS.MCSD has a 20 day delivery here in The Netherlands whereas the Cram 3... and of course I can only settle with the best.


I awake 10:00 AM, pay a visit to the bathroom. I boot my computer and meanwhile I’m getting something to eat and of course some milk to wash my internals. My comp is up, I promptly log in and start the TechEd 2003 Exception Management presentation. I got to do this stuff next Monday so I better prepare well to let my first day of the new week be a success. My love is arriving later this afternoon so I’ve got plenty of time to finish up some freelance work still laying on my desk. But first relax a bit more on the couch while Ron Jacobs is explaining me what I should do tomorrow.
I’ve started to participate on “My roadmap to success”, Thanks John C. Maxwell!
Guess I’ll be watching Frans’s blog for the LLBLGen Pro release later today.
I’m currently heading towards feature completeness which means I’ll be moving my first alpha version to our production environment. This means I’ve got a number of system configurations and a live database server up and running. It’ll be the first time since February 2003 that my work will be shown to other development teams, sales people and service engineers. For my company this is the first application developed in a more OOP fashioned way as well as the first .NET application. Exciting! Next week I’ll be spending most of my time pushing features into the first alpha release. Parallel I’ll do a massive review of my unit tests. Besides all of the standard crunching tasks I’d like to spend some time thinking about how the hell I’ll be dealing with all the user feedback. I really, really need to setup logging (tracing) and possibly debug output facilities. I added a class in the Core namespace of my app with a handful of static methods named DebugHelper which I used as “my little helper” while practicing XP, scanning over debug output in NUnit. My idea is to change the actual implementation a bit so that I can use DbMon.exe, PerfMon.exe and standard I/O through logging stuff in an output.txt and Windows event logs. I found this excellent resource on gotdotnet QuickStart. I should spend way more time reading the .NET framework documentation instead of “just writing” code because there so much info to improve new or existing code by leveraging every bit of the framework itself. So my tip of the week is… read, dig and dream the Microsoft .NET Framework SDK. Spending about 70% of my spare time on this stuff feels so damn… well… geeky ;) I can’t believe I just blogged that.
More Posts
Next page »