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.
Related
I have a application written long time back using the MS Access as the configuration database. It was using OLEDB Provider (Jet Engine) for retrieving data from the configuration DB.
I intended to replace MS Access Db lightweight RDBMS which requires no additional installation requirements. Thinking of using SQLLite which seems to suite my needs. Wanted to check if anyone have invovled in migrating the data from MSAccess to SQL Lite. Is there an easy way to migrate the schema and data?
You can quite much transfer data and schema if you setup the ODBC driver for sqlite.
Once done then you can run append queries in Access to export to the sqlite database.
Of course with sqlite you don't get or have forms, reports or a coding language. So, you have to replace that part of Access with some other kind of development platform.
So, you need to get a ODBC driver for sqlite.
This one works well:
http://www.ch-werner.de/sqliteodbc/
So, once you done the above, then you can link from access to sql lite. You can even edit data with Access forms, or even run access reports against data in sqlite.
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.
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.
I've got a client who wants an ASP.NET MVC application. I'll develop it with VS.NET 2010 Express, demo it to him on my Linux server during its development (Mono supports ASP.NET MVC), and he'll eventually host it on a commercial provider running IIS.
Getting this done quickly is the name of the game. The only piece I'm missing here is the database layer. Ideally I'd use SQL CE and EF4. But SQL CE only works on Windows, and Mono doesn't support the Entity Framework anyway.
The only free Linq to SQL-like option I see is DbLinq. A quick test with that on a MySQL database had it erroring out on a table that had two foreign keys to a single primary key. A search on Google shows that this bug was identified, and a patch was created, two years ago or so. That the patch still hasn't been applied to the main source by now, and that this bug seems to affect so a common scenario, does not fill me with confidence on the production-readiness of DbLinq.
Even if it did work, it'd have to be with MySQL, as that's the only database I can expect to be available on both Linux and an eventual Windows server. (SQLite, Berkeley DB, etc., would all require some native drivers be installed on the server, which I can't count on.)
I don't know NHibernate. But from what I read, it requires manually creating XML mapping files... so I don't have to write SQL statements, but I do have to create mapping files? (Plus I'd need to learn how to use it.) Like I said above: Getting this done quickly is a goal here.
If I must, I will just pony up the $5 a month or so for a cheap ASP.NET hosting provider and use that to demo progress to the client, using SQL CE and EF4. But before I do that I'd just like to see if there are any other viable options. (It's kind of mostly an intellectual exercise by this point.)
So... any tips?
Does it really have to be a fully bloated ORM?
I recommend to have a look at some of the so called "micro-orm`s", especially my favourite one: Peta-Poco (http://www.toptensoftware.com/petapoco/)
Peta-Poco runs perfectly under mono and has an incredible performance. Even better, because of the small codesize (~1k lines of c#) it is very easy to understand what`s going on under the hood and you can easily change/extend the code to your needs. For the start you just have to copy the single .cs file in your project and you are ready to go.
Peta-Poco has a very well poco-mapping heuristic so you will get your c# objects out of the db with zero configuration for the most cases.
You COULD try Linq-to-SQL. Partially supported under Mono from 2.6, it supports many dbs under mono Release Notes Mono 2.6 (they are working with those of DbLINQ to make it).
Ah... Forget to learn quickly how to use nhibernate. It's very good but it's quite an hell. And creating the XML is the least (and with NHibernate 3.2 they have added their version of Fluent interfaces, so XML aren't anymore necessary I think. You can "code" your XML.)
Looking for a good embedded db for my asp.net apps while trying to avoid SQLExpress (I need it to be a downloable file(s) with no need to install at server), I found Firebird. But:
According to this:
http://en.wikipedia.org/wiki/Embedded_database#Firebird_Embedded
It has the same features as the classic and superserver version of Firebird, except that two or more THREADS (not just applications) cannot access the same database at the same time. So Firebird embedded acts as a local server for a single threaded client accessing its databases (that means it doesn't work properly for ASP.NET web applications)
According to this http://www.firebirdsql.org/en/development-net-provider/, however, there are some ASP.NET providers released.
Weekly builds of the ADO.NET Data Provider, the ASP.NET Web Providers and the DDEX provider can be found here.
So the question is: is it or is it not a good embedded db alternative to use in asp.net?
If not, what would you recommend instead?
I have fixed the wikipedia article , firebird 2.5 embedded is fully multithreaded and it is fully supported for asp.net
http://blog.cincura.net/231742-firebird-embedded-in-comparison-to-sql-server-compact-edition-4/
Also from what i have read on jiri's blog it is possible to run it on azure
http://blog.cincura.net/232332-using-firebird-inside-azure-without-vm-role/
and on amazon
http://blog.cincura.net/232333-amazons-ec2-micro-instance-and-firebird/
Yes, it is. And I believe it is one of your best options.
Specially because you will be running it in a non MS environment. I know PostgreSQL is a good Open Source DB, but it does not have an embedded version.
Your other option is SQLite.
One thing that might be worth looking at is SQL Compact. The latest version works with ASP.NET and runs in-process. All you need to deploy is a couple of DLLs.
I must confess I don't really know anything about Firebird so can't compare it directly.