BizTalk Server 2010 has the following system configuration
Server: Windows Server 2008
FrameWork: .Net 4.0
Through HTTP when BizTalk receives the DateTime combination, it is being converted as follows.
DateTime Sent: **2010-06-01T00:00:00-04:00**
DateTime Received and logged: **2010-06-01T00:00:00-04:00** (BizTalk 2010)
In the BizTalk 2004 (our old integration environment, using .Net Framework 1.1), BizTalk is receiving and logging the message in the following formats.
DateTime Sent: 2010-06-01T00:00:00-04:00
DateTime Received and Logged: 2010-06-01T00:00:00.0000000-04:00
As it can be seen that leading zeros are being added to the DateTime. Following are some more combinations that are being a mystery to me.
Datetime Sent to BizTalk 2004: 2011-03-01T00:00:00-05:00
DateTime received and Logged: 2010-06-01T00:00:00.0000000-04:00
The schemas are defined in both the environments as xsd:dateTime. I'm unable to find an explanation to the fact that why BizTalk or the framework is behaving differently in both the environments.
Note: No Date Transformation occurs in any of the environment.
In BizTalk 2010, I can see that the TimeZone (-4:00) is missing.
Would like to know if there are any settings that we need to do fix for this DateTime issue.
You will need to change the timezone on the server (or servers in the group). BizTalk Host Instances use the time zone and regional settings from the machine.
Don't set the time zone programmaticly from your application code, since processes and threads can be shared across multiple instances and you will run into very nasty problems.
Check what are the Timezone settings of the servers in the registry
You can find the key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
However, pelase make sure you take a backup of your registry before making any changes.
Related
So my company has an old legacy .NET 4.5 web application running on IIS (version 8.5.9600.16384) in which it's application database resides on Microsoft SQL Server 2014 (SP3)... This works perfectly fine.
However (due to decommissioning / upgrades) we want to move the database to our SQL Server 2019 Server. So I took the original .NET package and re-imported it >> during the wizard I entered the SQL Server 2019 Server / db path and renamed the solution name with '_TEST' suffix >> then restarted IIS. The resulting connection string looks like this (as expected / mirroring the original working one however with the new server / db / uname):
connection string in IIS
When I go to test logging in to the web application (via IE11), I get the following "an error occurred while communicating with the database" error after clicking login:
Error message
We also tested the same exact SQL Server 2019 connection string through Powershell on this same web server and we are able to connect into the database, so it would seem that there's some mechanism failing inside the .NET application whether there's a configuration or driver not quite right somewhere.
Does anyone have any suggestions as to what I could potentially try next or what the issue might be here?
It seems you need to use the correct connectionstring. I know it works in your previous sql server 2014. Please follow the below steps to get the connection string, and replace it in your web.config. And the settings sync to your IIS.
If there also have any errors, you can update your post.
Steps
open your vs2019, and open sql server object explorer .
Add new server, and type the information to connect your sql server 2019.
After connect to the sql server, please click the Properties to copy the Connection string.
I'm having some trouble using Windows Azure Cache Preview.
I've add the Nuget Package here: http://nuget.org/packages/Microsoft.WindowsAzure.Caching and have configured my role for storing the ASP.NET sessions state as per the info on windowsazure.com
Problem is, I get No connection could be made because the target machine actively refused it 127.255.0.0:20004 when debugging. The dev IP used by Azure is 12.7.0.0.1:81
I'm not sure why, even the sample Windows Azure Caching (Preview) Session State and Output Caching Sample does the exact same thing.
Update: error from log:
w3wp.exe Error: 0 : ERROR: <SimpleSendReceiveModule> b4551065-941b-4bdb-9487-57d9207af308:Request - 1, result - Status=ChannelOpenFailed[System.Net.Sockets.SocketException (0x80004005): No connection could be made because the target machine actively refused it 127.255.0.0:20004
at Microsoft.ApplicationServer.Caching.AsyncResultNoResult.EndInvoke()
at Microsoft.ApplicationServer.Caching.TcpClientChannel.ConnectionCallback(IAsyncResult result)] for end point [net.tcp://127.255.0.0:20004]
Also, more testing shows it is just not for session state storage, but all cache related tasks.
found the answer , in the webrole or workerrole properties, set the number of instances to minimum 2, this is the issue for me. got it resolved after 8 hours of debugging
I haven't seen this error personally so I'm taking a couple stabs in the dark...
Did you enable the caching preview in the role properties tab? That step sets up the "server" side of the caching solution.
You also need to make very sure that the names in the various configurations are consistent or the caching client won't be able to find the service. You should find one of these in the web.config in the dataCacheClient section. SPecifically the identifier attribute.
For others that have the same problem, there are two other possible solutions in case the resolution proposed by Sundara Prabu does not work:
simply reboot your computer, as suggested in this thread on MSDN forums;
in the Regional Settings of Windows change the Long Time format to HH:mm:ss. As I discovered myself by reading this SO answer, the cache emulator calls logman.exe for logging purposes and in particular, it uses the cnf parameter, that requires a duration in the format HH:mm:ss. The cache emulator instead formats this duration using the Long Time format found in the Regional Settings -- in my case, using Italian settings under Windows 8 the format used was HH.mm.ss, thus causing the problem described in the question.
Apparently, using AttachDbFilename and user instance in your connection string is a bad way to connect to a DB. I'm using SQL server express on my local machine and it all seems to work fine. But what's the proper way to connect to SQL server then?
Thanks for your explanation.
Using User Instance means that SQL Server is creating a special copy of that database file for use by your program. If you have two different programs using that same connection string, they get two entirely different copies of the database. This leads to a lot of confusion, as people will test updating data with their program, then connect to a different copy of their database in Management Studio, and complain that their update isn't working. This sends them through a flawed series of wild goose chase steps trying to troubleshoot the wrong problem.
This article goes into more depth about how to use this feature, but heed the very first note: the User Instance feature has been deprecated. In SQL Server 2012, the preferred alternatives are (in this order, IMHO):
Create or attach your database to a real instance of SQL Server. Your connection string will then just need to specify the instance name, the database name, and credentials. There will be no mixup as Management Studio, Visual Studio and your program(s) will all be connecting to a single copy of the database.
Use a container for local development. Here's a great starter video by Anna Hoffman and Anthony Nocentino, and I have some other resources here, here, and here. If you're on an M1 Mac, you won't be able to use a full-blown SQL Server instance, but you can use Azure SQL Edge if you can get by with most SQL Server functionality (the omissions are enumerated here).
Use SqlLocalDb for local development. I believe I pointed you to this article yesterday: "Getting Started with SQL Server 2012 Express LocalDB."
Use SQL Server Compact. I like this option the least because the functionality and syntax is not the same - so it's not necessarily going to provide you with all the functionality you're ultimately going to want to deploy. Compact Edition is also deprecated, so there's that.
Of course if you are using a version < SQL Server 2012, SqlLocalDb is not an option - so you should be creating a real database and using that consistently. I only mention the Compact option for completeness - I think that can be almost as bad an idea as using AttachDbFileName.
EDIT: I've blogged about this here:
Bad Habits : Using AttachDBFileName
In case someone had the problem.
When attaching the database with a connection string containing AttachDBFile
with SQLEXPRESS, I noticed this connection was exclusive to the ASP.NET application that was using the database. The connection did block the access to all other processes on the file level when made with System.Data.SqlClient as provider.
In order to assure the connection to be shareable with other processes
instead use DataBase to specify the database name in your connection string
Example or connection string :
Data Source=.\SQLEXPRESS;DataBase=PlaCliGen;User ID=XXX;password=ZZZ; Connect Timeout=30
,where PlaCliGen is the name (or logical name) by which SQLEXPRESS server knows the database.
By connecting to the data base with AttachDBFile giving the path to the .mdf file
(namely : replacing DataBase = PlacliGen by AttachDBFile = c:\vs\placligen\app_data\placligen.mdf) the File was connected exclusively and no other process could connect to the database.
I recently copied a web application to a new install of Windows 7 and SQL Server 2008 R2. The application uses LINQ to SQL. Somewhere along the line the parsing of POSTed date strings got screwed up. When the user enters a date string like 4/23/2011, the application rejects it, throwing the error The value '04/23/2011' is not valid for Due. Due (actually DueDate) is a DateTime field in SQL Server.
This used to work fine. I assumed it was an issue with the machine's OS internationalization settings, so I checked and the short and long date formats are set to MM/dd/yyyy and dddd, MMMM dd,yyyy respectively, which looks OK to me. The SQL Server database language is set to English.
The partial class for this property looks like this:
[DisplayName("Due")]
[DisplayFormat(ApplyFormatInEditMode = true, DataFormatString = "{0:MM/dd/yyyy}")]
public DateTime? DueDate { get; set; }
There must be another date format setting I need to tweak. Where should I be looking?
Note: this may be more correctly a serverfault question, but I think devs are much more likely to run into this issue than sysadmins.
More info: SP_CONFIGURE 'default language' returns:
default language 0 9999 0 0
Also: the default language for the database login I am using is English.
I assumed it was an issue with the machine's OS internationalization settings
No, it uses th USERS internationalization settings as told the server by the browser.
the application rejects it, throwing the error The value '04/23/2011' is not valid for Due.
And that is purely bad programming. You should always (!) enter dates either through a parameter or in the ISO form which is totally independant, if you really insist on creating your SQL strings yourself. That woudl be 2011-04-23. SQL Server will accept that format regardless of the locales set somewhere on client or server.
I'm having a major issue trying to configure a new install of BizTalk Server 2006 (not R2). The server had BizTalk installed on it before, and it was working fine. I've uninstalled BizTalk, removed the databases and jobs from the SQL server, which is a separate machine, and re-installed BizTalk. The install was successful, with no errors during the install, and nothing in the install logs.
I'm configuring the BizTalk server to be the SSO master secret server, along with creating a new BizTalk group and registering the BizTalk runtime. The process always errors out on creating the SSO database on the SQL server. In the ConfigLog, there are a couple of warnings that the MSSQLServerOLAPService does not exist, then it shows errors on creating the SSO database. There are 4 in a row. In order, they are:
Error ConfigHelper] [DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
Error ConfigHelper] SQL error: 08001 Native error code: 17
Error ConfigHelper] c:\depotsetupv2\private\common\configwizard\confighelper\sqlhelper.cpp(1176): FAILED hr = 80004005
Error ConfigHelper] c:\depotsetupv2\private\common\configwizard\confighelper\sqlhelper.cpp(918): FAILED hr = 80004005
It then has similar errors trying to create each of the BizTalk databases.
On the SQL server, there are corresponding errors in the SQL Server Logs - 2 for each attempt
Login failed for user '[USERNAME]'.[CLIENT: [IP ADDRESS]]
Error: 18456, Severity: 14, State: 16
The first error from the SQL logs also shows up as a failure audit in the SQL server's application event log.
The biggest issue I am having with this is that the user I am logged on to the BizTalk server is a local admin on both the BizTalk server and the SQL server, and is in the SQL sysadmin group. The user that I am configuring the BizTalk services to run under is also a local admin on both servers and in the sysadmin group on the SQL server. I've checked the MSDTC settings on both machines and made sure they are set as the BizTalk documentation recommends. SQL Browser is running on the SQL machine, and I've verified that network access is allowed using the SQL Surface Area Configuration tool.
Can anyone help me find something that I might have missed?
Re: Igal:
Yes, all of the servers and users are on the same domain. I've run across that posting on SQL protocols in researching this, but I tried to select a count from one of the tables in the default database of the logged in user while connected to another database. I had no problems at all running that query.
Re: Yossi:
I'm installing BizTalk on Windows Server 2003 R2 SP1. Yes, I have removed the SSODB (Wouldn't out it past myself to miss something like that though!). I will make sure I am providing the usernames correctly and check out the sources you linked and get back to you.
A few of pointers:
Check out the two points at the end of the Configuring Enterprise SSO Using the Configuration Manager page on MSDN:
When configuring the SSO Windows
accounts using local accounts, you
must specify the account name without
the computer name.
When using a local SQL Server named
instance as data store, you must use
LocalMachineName\InstanceName instead
of LocalMachineName\InstanceName,
PortNumber.
Check out the relevant installation guide (don't worry about the fact that it relates to R2, they seems to have hidden the 'R1' documentation, but they are the same), and specifically the section around "Windows Groups and Service Accounts"
also - just to be sure - when you have uninstalled BizTalk and removed the databases - you have removed the SSODB as well, right?! :-)
The log files are very confusing - especially when deciding which error is the acutal problem - have you tried looking up any other errors you've had? (check out this blog entry, for example)
I had everything set up properly. Unfortunately for me, the answer was the standard "Windows" answer - reboot and try again. As soon as I rebooted the SQL server, I was able to configure BizTalk just fine.
I am going to set Yossi's answer as accepted, however, since that would be the most relevant for anyone else who may be reading this question.
Just remember to reboot after all setting changes!
Make sure the BizTalkMgmtDb and BizTalkMsgBoxDb have your local admin account as DB OWNER.
Right click on the databases --> Properties --> Files --> Owner: