Totzkeeeeee's Blog

Just because I can...

  Home  |   Contact  |   Syndication    |   Login
  216 Posts | 4 Stories | 345 Comments | 321 Trackbacks


My blog is worth $14,678.04.
How much is your blog worth?

Tag Cloud


Post Categories

Blog Roll

Cool Sites

I've been working with our ERP system lately trying to do some BizTalk integration.  Pretty simple conceptually but a royal pain in the ass when you get right down to it.  We use Navision and it is hosted on the original C/SIDE database management system.  ick.

Now, if you are programming within Navision itself, life is not so bad.  If, on the other hand, you have to get at the database using the ODBC driver, things get a little odd.  The first thing that is weird is that you have to install the Navision client application before you can set up a DSN.  I think that it's just because that installs a data access dll.  I could do without the full client on my BTS machine.

C/SIDE doesn't support stored procedures.  That means building the SQL in code.  Now, this isn't in and of itself all that bad but when you add in the fact that the people that named the tables and fields in Navision were completely insane, it all starts to get ugly.  For example:

POLineItem.CommandText = "SELECT \"Document No_\", \"Expected Receipt Date\", Quantity, \"Line No_\", No_ FROM \"Outbound Purch_ Document Line\" WHERE \"Line No_\" = '" + ItemLineNumber + "' AND \"Document No_\" = '" + PONumber + "'" + " AND \"Expected Receipt Date\" = '" + ExpectedReceiptDate + "' AND Quantity = '" + Quantity + "'

I'll give you a moment to let your stomach settle...

Feel better now?  Good.  Sorry about that.  That statement never did actually work.  The C/SIDE ODBC driver has it's own way of dealing with dates and it's not talking.  Interestingly enough, if you attach the tables in Access and write a query using #01/01/2004# like normal, JET somehow figures it out and the query works.  Sadly, JET is silent on what magic it invokes to accomplish this.  It seems that C/SIDE's concept of datatypes is fuzzy at best.  In our recent tests for converting to a SQL 2000 backend, we've discovered thousands of transactions with invalid dates.  Dates prior to 1753, the beginning of the Gregorian calendar.  Neat.

I  was playing with this in a Windows Forms application and then copied the code into my BizTalk AIC (which is a whole other story but your stomach is probably still too queasy) drop that into COM+ and...nothing.  Surprise number two.  Even though the default transaction setting for the component is “Disabled”, my little guy wanted in on the fun anyways.  The C/SIDE ODBC driver doesn't support distributed transactions.  Why should it?  It doesn't support much else anyways.  Changing the transaction setting of the component to “Not Supported” cured that problem.

Lastly, it's S-L-O-W.  I mean really, really slow.  Hey, that's a hat trick! 

So cheer up, it could be worse, you could be me.

Just because I can...

posted on Wednesday, April 14, 2004 9:09 PM