I needed this today! While developing a custom web part for Sharepoint 2013, I discovered there are some quirks when writing client-side javascript.
Instead of:
document.getElementById(“TextBox1”);
Use this:
document.getElementById(“<%=TextBox1.ClientID %>”);
It’s a bit of a pain to have to do this. But, it works.
I needed this method to create a custom picture library for a client.
http://technostropic.com/2014/05/29/sharepoint-2013-custom-picture-library-creation-deployment/
It works!
Good to know!
This is a handy SQL script created to clean up/purge ESBExceptionDb database for fault messages for particular days. This has been created only for development & testing purpose and is suggested not to run in Production environment unless you understand the use and circumstances. You can also schedule this as job once tested and verified the behavior of the script.
USE [EsbExceptionDb] GO IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[x_Delete_ESB_Faults]') AND type in (N'P', N'PC')) DROP PROCEDURE [dbo].[x_Delete_ESB_Faults] GO USE [EsbExceptionDb] GO SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO CREATE PROCEDURE [dbo].[x_Delete_ESB_Faults] @DaysToKeep INT = 7 AS BEGIN /* ============================================= Example: EXEC [dbo].[x_Delete_ESB_Faults] @DaysToKeep = 1 ============================================= */ DECLARE @currentDateTime DATETIME, @deleteFromDateTime DATETIME; SET @currentDateTime = GETUTCDATE(); SET @deleteFromDateTime = @currentDateTime - @DaysToKeep; SET NOCOUNT ON; /*Deleting…
View original post 334 more words
I was having a “forehead to keyboard” sort of issue with SVN at a client. Something in the repository got jacked up, so I couldn’t run a cleanup operation. The frustrating thing was that when I ran the cleanup operation, it would give me an error message telling me the clean up failed, and instructed me to run the cleanup operation! Really?! 🙂
I found this blog post, and that fixed my issue…
Solution:
Somehow, svn is stuck on the previous operation. We need to remove this operation from it’s ‘work queue’.The data is stored in the wc.db sqllite database in the offending folder.
1. Install sqllite (32 bit binary for windows) from here
2. sqlite .svn/wc.db “select * from work_queue”The SELECT should show you your offending folder/file as part of the work queue. What you need to do is delete this item from the work queue.
3. sqlite .svn/wc.db “delete from work_queue”
That’s it. Now, you can run cleanup again – and it should work. Or you can proceed directly to the task you were doing before being prompted to run cleanup (adding a new file etc.)
As many of you may know, the BizTalk Server Pipeline Component Wizard project on Codeplex only works on BizTalk 2010 and prior. More specifically – the wizard does not work with Visual Studio 2012 or 2013. This has left me copy-and-pasting from prior classes whenever I needed to author a new custom pipeline component.
Well, I was perusing the Nuget gallery in Visual Studio 2013, searching for BizTalk to see what was out there. And lo and behold, I find the Breeze BizTalk Pipeline Component Project.
When you add the Nuget package to a class library, it creates the necessary references to the BizTalk assemblies…
It also creates a template class that you then modify to suit your needs (MyPipelineComponent.cs). Just rename the class, change the namespace as needed, and follow the handy instructional comments at the top of the code module. (And don’t forget to sign your assembly so you can put it in the GAC!)
There is a single property implemented (MyProperty) so you will want to make the necessary code changes to implement your properties.
All in all, a really nice helper since the wizard project has not been carried forward. Great idea and thanks to the guys at Breeze.net for putting it out there!
When executing a stored procedure from a WCF send port (generated by the BizTalk Consume Adapter Service function in Visual Studio) I would receive the following exception:
The adapter failed to transmit message going to send port “WcfSendPort_SqlAdapterBinding_TypedProcedures_dbo_Custom” with URL “mssql://server/database?”. It will be retransmitted after the retry interval specified for this Send Port. Details:”System.Data.SqlClient.SqlException (0x80131904): The current transaction cannot be committed and cannot support operations that write to the log file. Roll back the transaction.
The stored procedure was already in place; written by a client and contains a good bit of logic. So, I had only a little leeway to make changes. I discovered the issue had to do with transactions between BizTalk and SQL Server, and a TRY/CATCH block within the stored procedure. Apparently, they don’t work well together unless you also use an explicit BEGIN/COMMIT/ROLLBACK transaction within the stored procedure.
Sure enough, when I added a BEGIN TRANSACTION before the TRY, a ROLLBACK within the CATCH, and a COMMIT at the end of the procedure, things worked correctly. I used the syntax given at this link (scroll down to Error 16).
USE Adventure Works;
GO
-- This was added to fix the error
BEGIN TRANSACTION;
BEGIN TRY
-- The logic is here
END TRY
BEGIN CATCH
-- The error handling is here
SELECT 1
-- This was added to fix the error
IF @@TRANCOUNT > 0
ROLLBACK TRANSACTION;
END CATCH;
-- This was added to fix the error
IF @@TRANCOUNT > 0
COMMIT TRANSACTION;
GO
I was receiving this error after installing the much-loved (haha) BizTalk ESB Exception Notification Service.
(I jest about it being much loved because these “sample” applications shipping with BizTalk 2013 R2 haven’t been maintained and tend to be a royal pain to install. But, they provide functionality that fills in gaps in the BizTalk feature set. But I digress!)
I was receiving this error message in the Event Viewer when trying to start the service:
Service cannot be started. Microsoft.Practices.ServiceLocation.ActivationException: Activation error occured while trying to get instance of type Database, key “” —> Microsoft.Practices.Unity.ResolutionFailedException: Resolution of the dependency failed, type = “Microsoft.Practices.EnterpriseLibrary.Data.Database”, name = “(none)”.
Exception occurred while: while resolving.
Exception is: InvalidOperationException – The type Database cannot be constructed. You must configure the container to supply this value.
Fortunately, it didn’t take long to find the solution on the MSDN forum (via Bing…shameless plug/admission).
Quoting the post on the forum thread (here’s the link)…
There are two issues with this service to be fixed after the installation to make it work. Assuming the service has been installed in the default folder “C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit\Exception Notification Service”, make the following changes:
1. Rename “BizTalkESBExceptionNotification.exe.config” to “BizTalk ESB Exception Notification.exe.config”
2. Open “BizTalk ESB Exception Notification.exe.config” file and replace the following line
<add name="AlertService" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=5.0.414.0,Culture=neutral, PublicKeyToken=31bf3856ad364e35" filePath="BizTalk ESB Exception Notification.exe.config"/>
With
<add name="AlertService" type="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.FileConfigurationSource, Microsoft.Practices.EnterpriseLibrary.Common, Version=5.0.414.0,Culture=neutral, PublicKeyToken=31bf3856ad364e35" filePath="C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit\Exception Notification Service\BizTalk ESB Exception Notification.exe.config"/>
While building a schema that was generated from a SQL Server stored procedure, I ran into this exception:
Specify a valid .NET type name for this root node. The current .NET type name of this root node is invalid (it is a reserved BizTalk Keyword or is an invalid C# identifier).
It turned out that the issue was the root nodes created for the typed procedure contained hyphens (because the stored procedure name contained hyphens). C# class names disallow the use of hyphens.
The solution was to open the properties dialog box for the root node (in this case there were two root nodes: one for the request and another for the response) and edit the RootNode TypeName property to remove the hyphens. This fixed the issue.
I found this solution on the MSDN forums here:
The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.
Here’s an excerpt:
A San Francisco cable car holds 60 people. This blog was viewed about 3,000 times in 2014. If it were a cable car, it would take about 50 trips to carry that many people.
Helpful…
A small oversight (at least in my mind) in the ESB Portal quickly proves to become a major irritant after using it for awhile. The default sort order on the faults page is by severity, which if you’re like me, is almost never the logical choice when viewing the page. I would much rather be seeing it sorted by the time when the fault occurred and if I want to view the data any other way I can always change the sort order or apply filters.
The ESB portal uses an ASP.Net Grid and it’s default implementation doesn’t specify a sort order, thus on page load it will always sort by it’s first column which is severity. Thus you’ve got two choices, either change the order of the columns, or add some new behavior which defines the default sort behavior. I’ve explored the latter path.
In order to make the changes…
View original post 191 more words
John Glisson - Geek of the Cloth 