Is SQL Server 2019 Extensibility Framework is the equivalent of Postgres extensions. I think both are NOT exactly same based on below articles.
what is the exact difference between these two.
https://www.postgresql.eu/events/pgconfeu2019/sessions/session/2641/slides/265/Implementing%20your%20first%20PostgreSQL%20extension.pdf
https://nielsberglund.com/2019/06/06/sql-server-2019-extensibility-framework--external-languages/
At a glance they are not very similar. The PostgreSQL extensions appear more similar to SQL Server CLR Integration as a means to extend the database engine with functions, procedures, types and aggregates (plus more extensibility points in PostgreSQL), running inside the database engine.
The SQL Server Extensibility Framework is a way to run custom code outside the database engine, through a special stored procedure sp_execute_external_script. The emphasis is on safely supporting multiple languages (Python, R, Java, C# (.NET Core)) with permissive permissions and bring-your-own libraries, intenteded primarilly for machine learning applications that need to bring compute close to the data, but not necessarily inside the database engine.
Related
We've got a couple of on-premises dbs and we're seeing if we can migrate them to SQL Azure. Some of those dbs have a couple of user defined functions written in C# in an assembly (SAFE). After running a search, I've found a couple of posts which contradict each other. Some say that v12 supports CLR code. Others say it doesn't. So, here are my questions:
Does V12 supports embedding clr assemblies?
How can we export the generation script for azure with the assembly? Whenever we set the export option to azure we end up getting an error saying that clr user defined functions are not supported in azure.
Thanks guys!
Luis
CLR Functions are not supported in Azure:
Check here:
Azure SQL Database Transact-SQL differences
Under unsupported features it mentions ".NET Framework CLR integration with SQL Server"
I believe there may be some confusion as to whether it does or doesn't support them as they used to in one version, then they removed support.
Here is a link detailing the fact they were supported, but got pulled, apparently due to a security issue:
Breaking News, Literally: SQL CLR Support Removed from Azure SQL DB
Azure SQL support now CLR using Azure SQL managed instance.
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-managed-instance-transact-sql-information#clr
Using managed instance you can have almost all support benefits of an on premise including C# CLR. To access the instances you have to use SSMS Preview 6 of SQL Server Management Studio 18 or TSQL.
You have 2 choices:
Use Azure SQL managed instance (very expensive, more than $1000 per month)
Create an Azure VM and install SQL Server on it (much cheaper, less then $20 per month)
The title says it all: as we are nearing release of our desktop application, which uses a local database (SQLServer 2014 LocalDb), we want to password protect access to it.
The database will be created using EF Code First on the user's computer the first time he starts up the application.
This must be really simple, but I seem to overlook the solutions that should present itself on Google.
The short answer here is you can't password protect LocalDb. LocalDb is designed to be a low friction database setup for development and testing, but it does not provide any of the advanced features of SQL or even SQL Compact Edition. From MSDN:
LocalDB is created specifically for developers. It is very easy to install and requires no management
and then there is this:
Moreover, if the simplicity (and limitations) of LocalDB fit the needs of the target application environment, developers can continue using it in production, as LocalDB makes a pretty good embedded database too
"pretty good" implies that while it will work, there may be better solutions. Essentially, the lack of security is a feature of LocalDB. It is designed to run as the currently logged in user, giving them full access.
If you need Database Security as a feature of your deployed application, but do not want to deal with the complexities of a full SQL installation, you should consider SQL Compact Edition.
See this article How to: Deploy a SQL Server Compact 4.0 Database with an Application. Deployment will vary depending on the deployment methods used by the rest of your application.
Entity Framework is an abstraction layer which is not specifically tied to a specific database technology. It will work identically with LocalDb, SQL Compact, SQL Express, MySQL, postgresql, etc... usually with nothing more than than the correct database driver and the correct connection string supplied.
I am getting a little bit confused about the difference of the followings:
SQL Server Express
SQL Server Compact
localDB
My requirement is to develop a desktop application that will use basic RDBMS features. I need to package the application and allow the user to install a single distributed package. I don't want the user to install even SQL server express.
In this case, which DB I should use? SQLite is not considered as too much re-coding has to be done.
Thank you.
SQL Server Express is full featured DBMS, with some limitations in terms of database size and resources it is allowed to use. You can see it's limitations (relative to SQL Server) on microsofts site (Features Supported by the Editions of SQL Server 2012)
SQL Server CE is embedded database, meaning that it runs in user mode, it's easy to deploy (requires you to copy just few assemblies), lightweight but fast, can be run by a low privileged user. It's supported by NHibernate. However, has more limitations. To me most notable is that there are problems when you try to have multiple connections to same database. Although MS claims that this is supported, if you try this in Windows 2008 server, you will fail. And what's worse, such use scenario may lead to DB corruption. This means that you will effectively not be able to use some Management tool to update data while your service/website is running. Also, SQL Server Management studio doesn't support SQL CE anymore, so you will have to use a 3rd party tool, like Database.NET. It also does not support subqueries.
localDB, having not used it, sounds like a compromise. It's a standalone database which is executed in user mode (can be used by low privilege user), but must be installed so you will need administrative privileges for that part. Offers set of capabilities of SQL Server Express. It's much larger than SQL CE, and also requires to be installed (unlike CE which is just binary drop in). Shortest overview of this DBMS can be found here.
When I open up VS2005 I can see one of the options for projects is "SQL Server Project"?
What would be the purpose of these projects? Would it be a place to put business logic for your application such that it could serve business objects to an app, or is that completely off-track?
You can use .NET Framework languages in addition to the Transact-SQL
programming language to create database objects such as stored
procedures and triggers, and to retrieve and update data for Microsoft
SQL Server 2005 databases
From the MSDN
hope it helps
I have a project requirement to choose a light database for the application.
It's required to choose between SQL Server Express Edition or SQLLite. Which one would be efficient and reliable. I am supposed to run it under Windows 7/Windows 2008 R2. I am newbie in the database programming. It would be helpful if you can share some information in terms of
Reliability
Stability
Size Limits
Memory consumption
Performance
SQL Server Express and SQLite aren't really comparable database systems.
SQL Server Express is the free version of Microsofts full SQL Server product, a standalone database server (often run on a dedicated machine) that client applications connect to. It is designed for things like web applications where many users will be using the database at the same time and there is a requirement for high availability.
SQLite is a compact in-process database that is often used in applications that benefit from having access to a SQL based database system however it isn't feasible to install a full standalone database alongside the application. For example Firefox uses SQLite to store bookmarks and Adobe Lightroom uses it to store its photos catalog, there are also several mobile (e.g. iPhone) applications that use SQLite.
The Microsoft equivalent to SQLite would be SQL Server compact edition (CE) which is free to distribute and use. SQL Server CE is very similar to SQLite in most respects.
Similarly the non-Micrososft equivalent of SQL Server (both the Express edition and the full edition) would probably be MySQL.
Although there are crossovers (you might build a small web application that uses SQLite, or a large desktop application that requires users to install SQL Express) typically the choice between the two "types" of database system (in-process vs standalone database server) is down to the type of application being developed.
You might find more details in the following article: http://erikej.blogspot.com/2011/01/comparison-of-sql-server-compact-4-and.html