Random Thunks

Tricky lil’ bugger this one.

We hit this error when trying to run a Estimated Query Plan on a users’ query. Didn’t make any sense since we’re SysAdmin’s on the server;  doubly-so since we could run a showplan elsewhere.

Turns out the offender in question was a call to msdb.dbo.sp_send_dbmail. Apparently bad funky things happen there if one tries a showplan on it. To solve it we simply commented out the call to the sendmail procedure out and then, the sky’s did doth part and our estimated query plan presented itself unto us..

Good to know…

I like online shopping – I do it a lot. I’ll admit that Amazon.Com has me hooked and I’d spend even more money there if the wife wouldn’t cut my fingers off at the core as a result. Target.Com is a new one for me to visit though. Done the retail store (a lot) and like it a lot (beats Wally World any day of the week), but their online inventory leaves something to be desired.

They try hard hard – real hard. When an item’s in stock they not only tell you that but also which Aisle it’s in (or endcap thereof). Real nice and useful however a total FAIL when it comes to reliability.

For me if your data’s not 100% correct it’s not worth pushing. And in Target’s case they seem to have an issue with the number of items on hand bit. Depending on whom we spoke to (wither store or via the phone) that figure could be 24 hours or even more out of date ; The web site continued to proudly inform us that our local Target had a particular item in stock even when it didn’t. Even checking over 24 hours later it still told us it was available even though it wasn’t.

This effect reminds me of a crowd I did some Sql Work for late in the last c. whilst I was still in the UK. Their name shall remain known only to me and them, however the story’s true. This crowd wanted an online system to punt their wares to Joe Consumer – all wizzywzggy flash driven utilizing Sql Server on the front and back end with replication to handle to the orders. Real nice right up to the point when there order’s then ended up on a printer somewhere awaiting an operator to actually input the order to the mainframe ‘at some later point’. This of course meant the at any point in time the inventory could could vary from accurate to ‘just a stab in the dark’.

I was reminded of this antiquated hand-cranked this system with my experience at Target; if you’re going to have an inventory indicator then it’d had better be accurate to, I don’t know, the last 60 minutes at least or else it devalues the web site forcing the consumer to have to resort to the phone to double check the inventory prior to (in our case) traipsing out in the bloody snow and cold).

Stupid, stupid, stupid.

You can either apply that to me thinking that attaching a file to my InfoPath task form would be easy or MS for allowing such a nasty insidious bug to crawl out into production.

Here’s the issue. I have an InfoPath task form running under MOSS Enterprise forms services. Upon this form I have a couple of file attachment controls. One would thunk that given that file attachment controls seem to have been a part of HTML since the mid 1990′s (RFC 1867) that this should be a totally elementary operation.

Heh, think again.

I found this out the hard way when, after browsing to my file and pressing the Upload button I was met with a rather curt ‘The Selected File was not found’ error message. A hunt around the blogsphere bore only one low dangling fruit : A WorkFlow that Uploads a Document via a Task using an InfoPath Form. which I gave a try but to no avail.

Turns out the author was 99.9998% there – except for the the direction of one slash! So, rather than regurgitate the entire post, here’s the correct JavaScript segment you need:

<script type=”text/javascript”>
     aspnetForm.encoding = “multipart/form-data”;
</script>

However, when all’s said and done I have to ask the question, why? Why do we have to slice up the WkTaskIP.aspx page to add this functionality in? I guess tomorrow I’ll be one the ole Dog n’ Bone to MS PSS to pursue this one further.

So, for anyone else out there with this issue, here’s a string for the search engines to chow down on to help any wayward travelers like myself get to the answer they need (at least for now!): InfoPath Forms Services File Attachment The selected file was not found

C’mon MS – We know it’s the year 2007 because we’re smart. You know it’s the year 2007 because you released this next version of IP and called it InfoPath 2007. So what’s the excuse for the horrific simplicity and mid-90′s ‘features’ that are browser based forms within IP 2007? Like for example the horrendously simplistic table layout control.

I mention this after I read the following support posting: How to resize the controls on a Microsoft Office InfoPath form based on the width of the form which states that in order to allow a table to grow and shrink with the page you pretty much have to remove any chance of editing the table layout via InfoPath unless you remove said functionality – both require you to edit the underlying views XSL.

Whisky Tango Foxtrot? And God-forbid we should be able to use something like style sheets to format the form – that would be far too 21st century!

I understand that IP’s heritage is client based but in this day and age of MOSS I wonder just how many forms are being produced that target the client? So far all of ours have been form based. This being the potential case just when are MS going to wake up, smell the coffee and make IP a far more functional web based forms editor?

Yeah yeah yeah – I know that you can always drop to using webparts or full ASPX pages for this stuff but why should you? IP is a pretty rich tool for forms filling – so why should we be expected the reinvent the wheel when all we want is to fill in forms?

It bugs me when the very ‘supposed’ leaders on MS product ‘code consistency’ don’t follow their own rules. Case in point: MOSS Task Activity events.

For example, the OnTaskChanged event has the following signature: (object sender, ExternalDataEventArgs e)

However the sender is always null. In order to get at the task that raised the event one needs to get at ((SPTaskServiceEventArgs)e).taskId.

Here therefore, are some others I’ve found to help my fellow ‘flow’ers to hook up multiple events to the same handlers (although I’m hoping that SP1 might ‘correct’ the lack of sender consistency):

OnTaskCreated

(object) sender or ((Microsoft.SharePoint.WorkflowActions.CreateTask)sender).ListItemId

Notes:

1. To get the name of the task that raised the event use sender.ToString().Substring(0, sender.ToString().IndexOf(” “)).

2. You’ll need to populate ListItemId in the designer – due to the nature of when this event is raised, there is no real useful info available prior to the call.

OnTaskChanged

(ExternalDataEventArgs) e

Notes:

1. To get at the tasks underlying GUID use ((SPTaskServiceEventArgs)e).taskId.

2. (object) sender is always null

OnTaskCompleted

(object) sender

Notes:

1. The tasks GUID can be located with ((Microsoft.SharePoint.WorkflowActions.CompleteTask)sender).TaskId.

2. The tasks name can be isolated with sender.ToString().Substring(0, sender.ToString().IndexOf(” “))

IfElse

(object) sender

Notes:

The name of the IfElse activity that raised the event can be found using sender.ToString().Substring(0, sender.ToString().IndexOf(” “)).

Not sure what’s worse, the fact that this ones escaped me until just now, or that it’s a ‘feature’ of workflow. I’m talking here about the fact that Initiation Forms do not get shown when a workflow is set to automatically start when a new item is created.

Like I say, It’s kinda embarrassing that I’d not seen this before but it’s also kinda very annoying. Not too sure about the logic behind this but I’m sure the boys and girls at Redmond have a really bloody good reason for it.

I guess the work around is to display the Initiation Form as a task form when the workflow has been started automatically. Dammit – that makes my ‘flow 7 states now – it’s getting mean and angry…

OK, I don’t get it. I’m trying to, honest but it’s not coming to me.

Why must one ‘publish’ browser based IP task forms to a ‘well known’ location before MOSS forms services will allow them to be opened? I think I get the full trust issue – dependent on who’s blog I read it’s either:

• Because the form’s being referenced by it’s URN,
• Because it requires access to external data via ItemMetadata etc, or
• Some other strange reason.

But for the life of me I can’t see why one needs to publish. From what I’ve seen thus far neither installing & activating the feature or using the ‘flow makes any attempt to reference the form at it’s ‘published’ location. Not only that, deleting the ‘published’ form makes no difference and the workflow carries on regardless.

So, here’s my take (based on all the scientific evidence 1 cup of coffee, 1 cup of tea, 1 large diet Dew and 1 Juicy 4-way Skyline Chili can muster): When a form is marked as trusted, it requires an extra step of publishing it to confirm the trust certificates validity on the form. When one sucks a form into MOSS all it cares about is confirming that the form has this confirmed trust. The location it was published to is neither here nor there.

Exciting, huh?

Phew – it’s been a while since I posted. It’s not that I’ve not got nothing to say just that I’ve been a wee bit distracted but some real nasty problems.

On the good side however MS finally got round to releasing the RTM version of the WSS 3.0 SDK. However in a big case of yaboo-shucks-to-you it’s not installable on a XP or Vista PC. Well – not unless you know the (albeit rather easy) magic key.

I know that everything you see, read and hear about MOSS development keeps on screaming that you should develop on a server, for me that’s not an answer – in fact IMHO it’s just downright wrong.

I’ve got a good development environment on my laptop. I have various 3rd party tools and VS add-ons that I’ve installed on it. I’ve got loads of extra stuff besides. In other words – it’s my development environment.

“Guns for show, Knives for a Pro” – Soap : Lock, Stock & Two Smoking Barrels.

OK, so MOSS development’s not quite the same as ripping off a brutal London based gang of their hard stolen dosh – however the theory still stands – use the right tool for the right job. Develop on a PC, test on a server. At least that’s my personal view.

And all this was working fine for me until today. I’d copied the requisite DLL’s from my MOSS Server to my laptop and registered them into the GAC. I could do all my development on my laptop then copy the files over using a simple batch script to the server prior to deployment. My post build script checked to make sure it would only execute the deployment side of things when it was on the server. All was happy in my world.

However today I find out that the newly released RTM version of the WSS 3.0 SDK won’t install on my Vista development environment. Fortunately there’s a very simple solution </rant>

Simply fire up regedit (or your favorite Registry Editor) an create yourself a new set of keys under HKLM called SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0. Now create a REG_SZ value called SharePoint and set it to equal Installed.

That’s it – everything else should then install nicely.

For the love of all that’s holy – I’m getting pretty tired of the total lack of error handling in MOSS. The latest one? A workflow that failed to start. Not only that but it failed to start for seemingly no reason. No error messages reported in the log file, nothing on the web page. The workflow itself looked as though it had never been run. Silence. Total abject silence. A silence so deafening one could hear the electrons race thru the CPU.

The reason for the lack of workflow action I found out (after a six hours of messing around) was a now defunct TaskListContentTypeId attribute in the <Workflow> entity located in workflow.xml. Granted the error was mine – don’t know when it became defunct, but defunct it was. However what I find so disturbing is that this situation obviously caused an exception to be thrown somewhere – so why on earth wasn’t it recorded anywhere?

Sheesh…

It finally happened – just like many other peeps out there in ‘pooter land (and other industries to boot), my previous employer decided to outsource all us DBA’s.

Sux – but what you gonna do?

So, I’ve now left my DBA days behind me and found a new evil to tame. S’long SQL Server 2005. Hello MOSS 2007 and all it’s idiosyncrasies (or which it has many of)…

All future posts will be brought by to you by the number 3 and the letter W. Promotional consideration (e.g. they now pay me my filthy lucre) is from NuSoft Solutions.