I am new to BizTalk development. I am using BizTalk server 2010. I am doing a migration existing code which use BizTalk 2006 to 2010. In the old application we have used Sql adapter to get procedure out put for a xml file.
MSDN for the 2010 specifies that
BizTalk Server no longer supports the SQL Adapter. Consider using the Microsoft BizTalk Adapter Pack to achieve the same functionality. (http://msdn.microsoft.com/en-us/library/aa578608.aspx)
But when I install BizTalk 2010 it has the SQL adapter.And they said that WCF_SQL adapter can use instead of SQl adapter. I want to know the difference between those two adapters. I found some blogs. But those wan't help me. If anybody knows please share it
Thanks
SQL Adapter has been available in BizTalk forever (not sure which version it came in with but since at least 2004). It works but it is very quirky to work with (for example, it wraps everything in an envelope mesage by default).
WCF SQL Adapter was designed to work with the latest versions of SQL server which have native support for XML as a sql type. It provides much better functionality and is much nicer to work with.
So there's good reason why you shouldn't use the SQL adapter any more.
The SQL Adapter is deprecated, meaning it will be removed from the BizTalk product base at some future version.
Functionally, the WCF-SQL adapter supports the majority of native types, both input and output, to Sql stored procedures, and is able to handle return data-sets without them explicitly converted to XML using the FOR XML, [AUTO|EXPLICIT] clause.
This last point simplifies the development effort required, and allows your team to use standard T-SQL stored procedure practices.
Related
We have a business application that was written a long time ago using classic ASP. Now we want to utilize the Always Encrypted feature of SQL 2016. From this article I saw that my only option is to use Microsoft ODBC driver 13.1, however that is not well supported using VB script because not all datatypes work.
Other than rewriting the whole application is there another way of utilizing Always Encrypted with classic ASP?
Is support going to be added in some future release of the driver?
The oledb driver is deprecated and not available for newer version of SQL Server.
The good new is the that Microsoft admitted they have made a mistake:
However, during subsequent reviews it was determined that deprecation
was a mistake because substantial scenarios within SQL Server still
depend on OLE DB and changing those would break some existing customer
scenarios.
and the oledb driver is no undeprecated. The new version will be released in March 2018. Unfortunately, the first version is going to support only SNAC 11.0.x functionalities, so nothing new that comes with SQL Server 2014+ is going to be supported:
The new release of OLE DB will not support Transparent Network IP
Resolution, Always Encrypted, Azure AD Authentication, Bulk Copy and
Table Value Parameters to begin with.
You can wait for the new version of the driver that is going to support Always Encrypted. Otherwise, you can use two connections - one using the new ODBC driver where AE is needed, and one using the current OLEDB driver in order not to rewrite everything.
We're upgrading our systems to support clustering and auto failover features. Our business runs .NET 4 applications, web apps and services on SQL Server Express. We can upgrade to SQL Server Standard, but the cost has motivated us to consider other options. Is it a legitimate option to integrate our .NET data layer with ODP.NET? After searching, I have seen a tendentious statement or two in the negative (viz) and yet it would seem that people are doing it anyway. What development features in the Visual Studio IDE will we lose? Thanks for your help!
Well, I'm now working since 20+ years with Oracle and MS SQL Server, having done a lot of projects. Some projects are running now more than 10 years, with all the updates, maintenance and so on.
My quick answer is: Stay with MS SQL Server. Go to Oracle only, if you have really GOOD TECHNICAL reason, or if you are planning really an ENORMOUS database, and if you have enough staff to handle all thge administration.
The main reason is that SQL Server is much easier to maintain; and it also integrates greatly into the Microsoft environment.
Oracle, in contrast, has a steep learning curve. The handling of Oracle is much more "manual" then MS SQL Server. Well, that's also a good thing, because you are in control of every small detail, but it also means that you need to learn a lot; or you need to pay experts. And it is not so easy to find people who really know what to do.
I really like both Systems, but for a rule of thumb, I normally suggest to use MS SQL Server.
I've been using .net with Oracle for years, and migrate away from it whenever the option is available.
If all your database code is in stored procs and you call it though the codebehind or a library and you use ansi sql your migration from ms sql to oracle will be fairly painless.
If you use TableAdapters, they re-write any sql you put in to the oldschool oracle 8 syntax like table1,table2,table3 then have a big where clause to do the join conditions. There's also some weird bugs where sometimes sql that runs fine over in SQL Developer won't work in the TableAdapters.
If you use Entity Framework migration should be pretty easy, but the MS SQL driver is much better then the Oracle one. There have been several queries I couldn't do though EF in oracle because of some of the various errors with the current driver.
If you need more info let me know.
Also if Cost is the main reason to consider migration, why not go with mysql?
Since you are already working in MS SQL, you must be habitual of the way it work, be it entity framework or any other data execution. Yes offcource, microsoft has very high license rates for it. But if you want to move to any other database, it is perfectly alright. I have personally used MS SQL and MySQL both. Initially you might face some syntax related issues, but do remember that logic remains the same for fetching and saving the data. Further it gives a benefit that you got to learn a new language and that too at the expense of far less money.
Environment:
ASP.Net 4.0
MVC 4
SQL Server 2005
Visual Studio 2010
Issue:
We have an SQL 2005 Database which is transactionally replicated to a separate server because a number of large business queries are run against the data and slow the system down. The secondary server is used for all reports (read only), while the primary server is used for day-to-day business. Our legacy code uses stored procedures to access the database and it was relatively easy to maintain different connection strings and have all reports use the report server connection string. We've recently started writing all of our newer code using Entity Framework for data access, however, and I'm at a loss for how to deal with the two different servers.
A simple solution would be, perhaps, to simply maintain two .edmx and point all of the reports to the second .edmx. I strongly dislike this method, however, as it requires that the developers maintain the two different files.
Has anyone else encountered this scenario and devised a more appropriate solution? Is there any way I can use the same .edmx for both servers (since they are identical) but somehow specify at the Controller or Action level which connection string to use?
Ideally I am looking for a solution that does not require manual SSDL writing. I'd like to continue to use the designer and "Update Model from Database" features.
Thank you for your time,
Mirzero
When creating the EntityContext object you can specify a connection string in the constructor. So you would just need to pass the required string to the method creating the EntityContext instance.
I need to extract Quickbooks SQL structure to make a Diagram about the tables that I need to work with. Could this be possible ?
I think QODC could solve my connection issue but I don't know how to extract SQL dump from it.
Thanks in advance
You can't directly access the QuickBooks SQL structure, so you're out of luck. Most versions of QuickBooks are not even based on an SQL backend (only Enterprise edition is), so it's not even applicable to those versions.
QuickBooks provides an XML-based API to adding/modifying/querying/deleting data within it, but does not provide direct SQL access. QODBC is a wrapper around the XML-based API which simply transforms XML requests into SQL requests, and vice versa. It is not reverse-engineering anything, it's simply transforming data from one format/protocol, into another.
You choices are to either use the XML API as is, use QODBC, or use the XML API and do something similar to what QODBC is doing by transforming the XML into an SQL-friendly format. I've done something similar with my PHP code, schema and code linked below:
MySQL Schema
QuickBooks PHP Framework
You can install QODBC, then setup a linked table in Sql Server Mgmt Studio.
From there, you can more or less query the tables out of QuickBooks into tables in a SQL Svr database.
With QuickBooks Enterprise 2011 this changed, and you can have real ODBC access (although with limited rights and to a limited amount of tables) and then use an SQL tool to map via the ODBC access.
QODBC publishes data layouts for all of the tables it exposes here. The format is really nice if you want to correlate a field on the QuickBooks screen to a table, which is usually what you need in a QuickBooks integration design process.
The company I work for has decided to join the 21st century and upgrade our main database cluster from SQL Server 7 to SQL Server 2005. As a web developer what new whiz-bang features of SQL Server 2005 should I get excited about or get to know?
Currently I'm mainly writing CRUD style queries, pretty much exclusively using Stored Procdures for a mixed ASP.net and Classic ASP environment.
system tables are now inaccessible, you will need use the system catalog views. Yes, some of your code needs to be rewrited.
partitioning. You can split very big table into two.
Try..Catch.
Common table expressions (CTE). It's like temporary tables, but more powerful.
Management server, that helps you to register your server groups and then use these groups from any another client place. (maybe it is in 2008 only? I cannot remember)
I don't know about your needs, but I was excited by mirroring. But I'm DBA :)
Some new types.
Snapshots.
Most of your code will still work :)
and many another things.
One that comes to mind is that you can integrate CLR / .NET code into SQL Server.
Here are some others.
My favorite new features are
varchar(max) nvarchar(max) data types
(much easier to work with than text,
ntext)
xml data type and Xpath support
Improved error handling with try...catch blocks
.NET code integration
Improved management interface
Common table expressions, PIVOT and UNPIVOT, APPLY
SQL 7? I'd start with the basics, like referential integrity and cascades. Or, you don't have to code your own triggers for all that stuff that Access was doing back in 98 or so when one had Sql 7.
Performance monitoring, profiling, tuning
Dynamic Management Views & Functions
http://msdn.microsoft.com/en-us/library/cc917696.aspx