I was wondering what is the way for the FILESTREAM data encryption (for example .docx files) in SQL Server? Is it Microsoft EFS or there is another solution?
Thanks in advance
As far as I'm aware, there's no encryption built into the FILESTREAM feature. I would generally expect the application fronting the database to handle any encryption of the data before sending it to the database and decrypting after retrieval.
"Is it Microsoft EFS or there is another solution?"
Since you asked about other solutions as well, there are two third party products that offer alternatives to TDE including FileStream encryption. They both work with all versions and editions of SQL Server. One is NetLib Encryptionizer for SQL Server and the other is DBDefence. Although they both work differently. Encryptionizer sits between SQL Server and the OS, while DBDefence injects code into the running SQL process using the (now defunct) Detours SDK. (Disclaimer: I am with NetLib Security).
We are currently using SQL Server 2008 Express Edition, but would like to upgrade to Standard Edition. Does it mean that we need a license with 20 seats, if we have 20 Active Directory users that are using the DB from a C# application?
If yes, does it make sense to switch from Windows Forms to Web Applications in order to decrease the amount of licenses needed?
Switching to a web app won't change the licensing needs of your application. If you have 20 users connecting to your SQL Server then you need 20 CALs for Standard Edition as whilst you may have a single "user" connecting to the DB you're still servicing 20 users. The MS license docs cover this in some detail.
The alternative approach for to go with per processor licenses. You obviously need to do the maths to work out which option is more cost effective for your user growth estimates.
Given that you're starting at 20 users the per user (CAL) route will probably be the cheapest option.
You have two types of licenses available to you, each with their own set of rules and scenarios where they make sense.
Per Processor License. Here you license each physical (or virtual if you are using virtualization and depending on the Sql Server Edition) processors.
Server/CAL license. Here you would buy a license for each server running Sql Server and Client Access Licenses (CAL) for each user or device. Note that a CAL would allow that user or device to connect to any number of SQL Servers without the need to buy additional CALs if you add additional servers. Also, any type of software or hardware that reduces the number of devices or users that directly access SQL Server (an example would be the use of a web application to reduce the number of users that connect to the database directly through connection pooling) would NOT reduce the number of CALs you get. You will still need to get them for each user using the web application.
The following microsoft link provides pricing points for Sql Server 2008 and also includes a Sql Server 2008 R2 Quick Reference, which includes all the information that you might need. We can see that based on the above link:
Per Processor would cost you $7,171.00
Server/CAL would end up being $4,178.00 based on the bellow calculations
Server $898.00
CAL $164.00 x 20 = $3,280
Total $898.00 + $3,280 = $4,178.00
Of course this is an estimate that doesn't include tax, discounts, or software assurance.
If you want more information I would recommend asking on serverfault
I have a client who is interested in hiring my company to do a small, custom, multi-user contact database/crm. They don't care about the technology I use, as long as the product is hosted inside their organization (no "cloud" hosting). Now the problem is that their IT department refuses to host any application developed by an outside company on their servers, additionally they will not allow any server not serviced by them inside of their network.
The only means of sharing data that IT would allow is a windows network share...
I was thinking to do the application as a fat client in Adobe Air, and let all users access a shared sqlite database, but then I read a lot of negative things about this approach.
So I'm asking you - Are there people out there who have actually tried this ?
What are your experiences ?
You can use an MS-Access 2007+ (accdb) file.
Of course there are many database engines with much more features and much better SQL syntax, but if you are looking for a file-based database system that can be accessed simultaneously by multiple processes on a shared Windows drive, then an accdb file is as good as you're going to get I think.
Also note that another popular embedded database, SQL Server Compact Edition, cannot be used on shared drives (at least not by multiple processes from different machines).
References:
Share Access Database on a Network Drive:
http://office.microsoft.com/en-us/access-help/ways-to-share-an-access-database-HA010279159.aspx#BM3
SQL Server CE Cannot be used on a shared drive:
SQLCE 4 - EF4.1 Internal error: Cannot open the shared memory region
The ways sqlite locks databases means you have to be careful if there's a chance you'll have multiple sources trying to access the database. You either have to develop a waiting method, or a timeout, or something
We are looking at creating a custom ASP.NET application for a client, however they are a nonprofit and thus budget is limited.
We typically develop ASP.NET web and desktop apps to connect to a central SQl Server 200X database, ie with a full version of SQL Server, running on networked Windows Server. In this case we won't have a full version available.
Are there any issues with using SQL Server Express in this sort of arrangement? IIS and SQL Server Express would be running on the same physical server, serving up pages over the local Intranet to users.
Any real differences to be aware of in regards to development of the app itself or deployment? This will be a fairly standard app, with SQL mainly being used for a datastore with tables and SPs, nothing really SQL Server specific beyond that.
SQL Server Express edition should be fine for this scenario. It has all the core features of the full product, but as you said you are only really using it for data storage and some SPs, then you will not need any of the additional functionality available in the other versions (ie. reporting and analysis services). There are some limitations to the express version (the biggest being that the maximum database size is 4GB), but they should not really affect you unless your are building a very busy ASP.Net application.
Some public-facing websites use SQL Server Express as the database server (DotNetKicks being the only one I can remember at the moment) without issue.
The exact list of unsuported features in Express is at SQL Server Express Features:
Database mirroring
SQL Mail
Online restore
Fail-over clustering
Database snapshot
Distributed partitioned views
Parallel index operations
VIA protocol support
Mirrored media sets
Log shipping
Partitioning
Parallel DBCC
Address Windowing Extensions (AWE)
Parallel Create Index
Hot-add memory
Enhanced Read Ahead and Scan
Native HTTP SOAP access
Indexed views (materialized views)
SQL Mail and Database Mail
Partitioned views
Online Index Operations
SQL Server Agent and SQL Server Agent Service
SSIS, SSAS, OLAP/Data Mining
The SQL Server Express with Advanced Services Features supports a "subset of Reporting Services features".
In addtion there are the operational restrictions:
Express will use onyl one CPU core
Express will not grow the buffer pool over 1 GB no matter how much RAM you have
Express will not allow any database to grow over 4GB and will not put online (restore, attach) databases that are already over 4 GB.
The key problems you may run into are the operational restrictions (one core, 1 GB ram, 4GB each database) and the lack of SQL Agent, preventing any sort of job scheduling.
You should not really run into anything, its actually a full featured product that MS SQL Express
Here's a really basic comparison from Microsoft.
I was reading a MS Excel help article about pivotcache and wonder what they mean by OLE DB and ODBC sources
...You should use the CommandText
property instead of the SQL property,
which now exists primarily for
compatibility with earlier versions of
Microsoft Excel. If you use both
properties, the CommandText property’s
value takes precedence.
For OLE DB sources, the CommandType
property describes the value of the
CommandText property.
For ODBC sources, the CommandText
property functions exactly like the
SQL property, and setting the property
causes the data to be refreshed...
I really appreciate your short answers.
According to ADO: ActiveX Data Objects, a book by Jason T. Roff, published by O'Reilly Media in 2001 (excellent diagram here), he says precisely what MOZILLA said.
(directly from page 7 of that book)
ODBC provides access only to relational databases
OLE DB provides the following features
Access to data regardless of its format or location
Full access to ODBC data sources and ODBC drivers
So it would seem that OLE DB interacts with SQL-based datasources THRU the ODBC driver layer.
I'm not 100% sure this image is correct. The two connections I'm not certain about are ADO.NET thru ADO C-api, and OLE DB thru ODBC to SQL-based data source (because in this diagram the author doesn't put OLE DB's access thru ODBC, which I believe is a mistake).
ODBC:- Only for relational databases (Sql Server, Oracle etc)
OLE DB:- For both relational and non-relational databases. (Oracle, Sql-Server, Excel, raw files, etc)
Here's my understanding (non-authoritative):
ODBC is a technology-agnostic open standard supported by most software vendors.
OLEDB is a technology-specific Microsoft's API from the COM-era (COM was a component and interoperability technology before .NET)
At some point various datasouce vendors (e.g. Oracle etc.), willing to be compatible with Microsoft data consumers, developed OLEDB providers for their products, but for the most part OLEDB remains a Microsoft-only standard. Now, most Microsoft data sources allow both ODBC and OLEDB access, mainly for compatibility with legacy ODBC data consumers. Also, there exists OLEDB provider (wrapper) for ODBC which allows one to use OLEDB to access ODBC data sources if one so wishes.
In terms of the features OLEDB is substantially richer than ODBC but suffers from one-ring-to-rule-them-all syndrome (overly generic, overcomplicated, non-opinionated).
In non-Microsoft world ODBC-based data providers and clients are widely used and not going anywhere.
Inside Microsoft bubble OLEDB is being phased out in favor of native .NET APIs build on top of whatever the native transport layer for that data source is (e.g. TDS for MS SQL Server).
ODBC and OLE DB are two competing data access technologies. Specifically regarding SQL Server, Microsoft has promoted both of them as their Preferred Future Direction - though at different times.
ODBC
ODBC is an industry-wide standard interface for accessing table-like data. It was primarily developed for databases and presents data in collections of records, each of which is grouped into a collection of fields. Each field has its own data type suitable to the type of data it contains.
Each database vendor (Microsoft, Oracle, Postgres, …) supplies an ODBC driver for their database.
There are also ODBC drivers for objects which, though they are not database tables, are sufficiently similar that accessing data in the same way is useful. Examples are spreadsheets, CSV files and columnar reports.
OLE DB
OLE DB is a Microsoft technology for access to data. Unlike ODBC it encompasses both table-like and non-table-like data such as email messages, web pages, Word documents and file directories. However, it is procedure-oriented rather than object-oriented and is regarded as a rather difficult interface with which to develop access to data sources. To overcome this, ADO was designed to be an object-oriented layer on top of OLE DB and to provide a simpler and higher-level – though still very powerful – way of working with it. ADO’s great advantage it that you can use it to manipulate properties which are specific to a given type of data source, just as easily as you can use it to access those properties which apply to all data source types. You are not restricted to some unsatisfactory lowest common denominator.
While all databases have ODBC drivers, they don’t all have OLE DB drivers. There is however an interface available between OLE and ODBC which can be used if you want to access them in OLE DB-like fashion. This interface is called MSDASQL (Microsoft OLE DB provider for ODBC).
SQL Server Data Access Technologies
Since SQL Server is (1) made by Microsoft, and (2) the Microsoft database platform, both ODBC and OLE DB are a natural fit for it.
ODBC
Since all other database platforms had ODBC interfaces, Microsoft obviously had to provide one for SQL Server. In addition to this, DAO, the original default technology in Microsoft Access, uses ODBC as the standard way of talking to all external data sources. This made an ODBC interface a sine qua non.
The version 6 ODBC driver for SQL Server, released with SQL Server 2000, is still around. Updated versions have been released to handle the new data types, connection technologies, encryption, HA/DR etc. that have appeared with subsequent releases. As of 09/07/2018 the most recent release is v13.1 “ODBC Driver for SQL Server”, released on 23/03/2018.
OLE DB
This is Microsoft’s own technology, which they were promoting strongly from about 2002 – 2005, along with its accompanying ADO layer. They were evidently hoping that it would become the data access technology of choice. (They even made ADO the default method for accessing data in Access 2002/2003.) However, it eventually became apparent that this was not going to happen for a number of reasons, such as:
The world was not going to convert to Microsoft technologies and
away from ODBC;
DAO/ODBC was faster than ADO/OLE DB and was also thoroughly integrated into MS Access, so wasn’t going to die a natural death;
New technologies that were being developed by Microsoft, specifically ADO.NET,
could also talk directly to ODBC. ADO.NET could talk directly to OLE
DB as well (thus leaving ADO in a backwater), but it was not (unlike
ADO) solely dependent on it.
For these reasons and others, Microsoft actually deprecated OLE DB as a data access technology for SQL Server releases after v11 (SQL Server 2012). For a couple of years before this point, they had been producing and updating the SQL Server Native Client, which supported both ODBC and OLE DB technologies. In late 2012 however, they announced that they would be aligning with ODBC for native relational data access in SQL Server, and encouraged everybody else to do the same. They further stated that SQL Server releases after v11/SQL Server 2012 would actively not support OLE DB!
This announcement provoked a storm of protest. People were at a loss to understand why MS was suddenly deprecating a technology that they had spent years getting them to commit to. In addition, SSAS/SSRS and SSIS, which were MS-written applications intimately linked to SQL Server, were wholly or partly dependent on OLE DB. Yet another complaint was that OLE DB had certain desirable features which it seemed impossible to port back to ODBC – after all, OLE DB had many good points.
In October 2017, Microsoft relented and officially un-deprecated OLE DB. They announced the imminent arrival of a new driver (MSOLEDBSQL) which would have the existing feature set of the Native Client 11 and would also introduce multi-subnet failover and TLS 1.2 support. The driver was released in March 2018.
• August, 2011: Microsoft deprecates OLE DB (Microsoft is Aligning with ODBC for Native Relational Data Access)
• October, 2017: Microsoft undeprecates OLE DB (Announcing the new release of OLE DB Driver for SQL Server)
On a very basic level those are just different APIs for the different data sources (i.e. databases). OLE DB is newer and arguably better.
You can read more on both in Wikipedia:
OLE DB
ODBC
I.e. you could connect to the same database using an ODBC driver or OLE DB driver. The difference in the database behaviour in those cases is what your book refers to.
Both are data providers (API that your code will use to talk to a data source). Oledb which was introduced in 1998 was meant to be a replacement for ODBC (introduced in 1992)
I'm not sure of all the details, but my understanding is that OLE DB and ODBC are two APIs that are available for connecting to various types of databases without having to deal with all the implementation specific details of each. According to the Wikipedia article on OLE DB, OLE DB is Microsoft's successor to ODBC, and provides some features that you might not be able to do with ODBC such as accessing spreadsheets as database sources.
At Microsoft website, it shows that native OLEDB provider is applied to SQL server directly and another OLEDB provider called OLEDB Provider for ODBC to access other Database, such as Sysbase, DB2 etc. There are different kinds of component under OLEDB Provider. See Distributed Queries on MSDN for more.
ODBC works only for relational databases, it can't works with non-relational databases such as Ms Excel files. Where Olebd can do everything.
To know why M$ invents OLEDB, you can't compare OLEDB with ODBC. Instead, you should compare OLEDB with DAO,RDO, or ADO. The latter largely relies on SQL. However, OLEDB relies on COM. But ODBC is already there many years, so there's a OLEDB-ODBC bridges to remedy this. I think there's a big picture when M$ invents OLEDB.