Aug 192008
 

In the initial entry, cialis and the follow up entry, view I showed the table/view structure of the components that I built.

Here are some examples of what is available so you can see the real values for each transaction reported.

Here are the settings for the pipeline configuration: (notice I am tracking 3 different objects in the data, pill so I can monitor these values through the flow of the data so I have a point of reference as far as counts)

edireport0

Because the table is so large, I am going to break it into chunks:

ediReportingView

 

edireport1
edireport2
edireport3
edireport4
edireport5
edireport6
edireport7
Aug 152008
 

I created an HTTP Post adapter and packaged it all up in a setup package. When I installed it, I opened up the management console and started to configure the adapter and I received the the following error:

Failed to instantiate adapter “{Adapter Name}”.

Assembly file: “{dll source}”

Type name: “{Type}”

instantiate

The problem was that the source was compiled with a dll that was on the development box, but not on the destination box. (In this case it was the Microsoft.Samples.BizTalk.Adapter.Common.dll) was not deployed to the GAC.

 

Once I put the assembly in the GAC, I didn’t have a problem.

Aug 152008
 

“There are no differences between BizTalk Server 2006 R2 and BizTalk Server 2006 except the enhanced EDI, malady WCF, ed and RFID functionality”

So I was creating a new HTTP Post adapter. I created it on a server that is R1.

When I copied the code to an R2 box and compiled the code and ran the Adapter Registry Wizard, viagra 40mg I got the following error:

Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

LoaderExceptions

The issue is that in the Transmit adapter project, it was referencing Microsoft.Samples.BizTalk.Adapter.Common that was not compiled on the R2 server.

The fix:

Simply Clean the project and Rebuild the project where it will tell you that a dll is missing.

LoaderExceptionsResolution

Aug 122008
 

On this BizTalk Glossary Page it states that a zombie ressurector is: An orchestration that listens at the MessageBox database for zombies and resurrects those that meet certain criteria.

The previous definition of a zombie is: A message that was not processed by an orchestration. It is not in the Suspended queue or anywhere else where it will be retried.

If there is an orchestration that is looking for ‘zombies’ – then they were never zombies were they?

Once you have answered that, then you can answer the question of which came first, the chicken or the egg?

Aug 122008
 

I have needed for some SQL jobs to run every second. I went into the Jobs and started to configure the job, unfortunately, the lowest value I can choose is minute:

scheduleGUI

So I found that in the script, the underlying values for Occurs (@freq_subday_interval) every are as follow:

 

Value Description (unit)
1 At the specified time
2 Seconds
4 Minutes
8 Hours

So I scripted the schedule like this:

EXEC @ReturnCode = msdb.dbo.sp_add_jobschedule @job_id=@jobId, @name=N'EverySecond', @enabled=1, @freq_type=4, @freq_interval=4, @freq_subday_type=2, @freq_subday_interval=1, @freq_relative_interval=0, @freq_recurrence_factor=0, @active_start_date=20080812, @active_end_date=99991231, @active_start_time=0, @active_end_time=235959

I got the following error:

Msg 14278, Level 16, State 1, Procedure sp_verify_schedule, Line 214

The schedule for this job is invalid (reason: The specified ‘@freq_subday_interval’ is invalid.).

Here is the logic in the sp_verify_schedule

IF ((@freq_subday_type <> 0x1) AND (@freq_subday_interval < 1)) OR ((@freq_subday_type = 0x2) AND (@freq_subday_interval < 10)) BEGIN SELECT @reason = FORMATMESSAGE(14200, '@freq_subday_interval') RAISERROR(14278, -1, -1, @reason) RETURN(1) -- Failure END

So there are a few things that can be done to get around it:

In the job use the following code:

EXEC stored_proc; WAITFOR DELAY '00:00:01'; EXEC stored_proc; -- again WAITFOR DELAY '00:00:01'; EXEC stored_proc; -- and again

Or by tracking through the various stored procedures (sp_add_jobschedule and sp_add_schedule) we see that the following table is where it ends up: msdb.dbo.sysschedules, so we can just go update the table after we scheduled the job.

UPDATE msdb.dbo.sysschedules SET name = ISNULL(@schedule_name, name), enabled = ISNULL(@enabled, enabled), freq_type = ISNULL(@freq_type, freq_type), freq_interval = ISNULL(@freq_interval, freq_interval), freq_subday_type = ISNULL(@freq_subday_type, freq_subday_type), freq_subday_interval = ISNULL(@freq_subday_interval, freq_subday_interval), freq_relative_interval = ISNULL(@freq_relative_interval, freq_relative_interval), freq_recurrence_factor = ISNULL(@freq_recurrence_factor, freq_recurrence_factor), active_start_date = ISNULL(@active_start_date, active_start_date), active_end_date = ISNULL(@active_end_date, active_end_date), active_start_time = ISNULL(@active_start_time, active_start_time), active_end_time = ISNULL(@active_end_time, active_end_time) WHERE schedule_uid = @schedule_uid

I decided to modify the sp_verify_schedule

IF ((@freq_subday_type <> 0x1) AND (@freq_subday_interval < 1)) OR ((@freq_subday_type = 0x2) AND (@freq_subday_interval < 1)) BEGIN SELECT @reason = FORMATMESSAGE(14200, '@freq_subday_interval') RAISERROR(14278, -1, -1, @reason) RETURN(1) -- Failure END

Did I happen to mention the disclaimer on the right side of my blog?

Aug 122008
 

While modifying a file for a BizTalk process for a client we kept on getting an Error using message tracking  in HAT looking like the following:

System.NullReferenceException: Object reference not set to an instance of an object.

   at Elite.EAI.Orchestrations.Receive_Orchestration.segment8(StopConditions stopOn)

   at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)
System.NullReferenceException
Scoped@
Receive_Orchestration.Trans_CobraScope
Receive_Orchestration.Receive_Orchestration
68223de9-f824-4fbb-868b-35dd6b61eb4b

The only thing that overcame this problem was changing the file name to something the BizTalk application recognized. In our case that was UPS for a UPS process. Adding a GUID also threw the same exception. Adding characters to the end didn’t throw the exception.

Aug 112008
 

By default, CLR is disabled (for security reasons of course), so if you think that writing C# code is easier to call stored procedures compared to actually writing the stored yourself, or otherwise want to extend what SQL Server can do out of the box, you need to enable it.

Here is how you do it:

sp_configure 'clr enabled', 1 go reconfigure go