I've read in multiples websites that Azure doesn't support encryption.
However I'm migrating (more like a backup) an Azure DB to SQL Server using the "Azure SQL Migration Tool" and I'm getting a warning about scripting the views: "Encrypted objects will not be scripted".
Also found this note in their site: Problem fixed in v3.5.5. Basically, Stored Procedures, Views, UDF, Triggers ... any object that can be encrypted is check before hand. The objects that are encrypted are highlighted in yellow with red letters. On the summary page, a list of encrypted objects that will not be scripted will be displayed.
http://sqlazuremw.codeplex.com/workitem/5762
If Azure SQL supports encryption, how can I get the creation script for this view?
Windows Azure SQL Database (database-as-a-service) does not support encryption. However: If you run SQL Server in a Virtual Machine, you should have all features at your disposal, including encryption.
I can't explain what's happening with the migration from SQL Database to SQL Server, regarding creation scripts involving encrypted objects on the target side.
SQL Database still doesn't support encryption, so either you are reading from a SQL Server database, or there is a bug in the Wizard. There are no encrypted database objects in SQL Database as far as I know. If you are sure you are reading from SQL Database, just try creating an encrypted view in it and see what happens. From the MSDN documentation, creating an encrypted view is not supported: http://msdn.microsoft.com/en-us/library/windowsazure/ee336244.aspx.
I am curious to know if you are getting the same error with Enzo Cloud Backup: http://www.bluesyntax.net/backup20.aspx. Just use the free edition.
Related
I am new to Oracle database and I wanted to create a database in Oracle. I followed this link to create a database:
http://www.fehily.com/books/createdb/createdb_oracle_11g_2.html
In Microsoft SQL Server, when we create a database, we use the create database command and the database creation is instantaneous [within fraction of seconds], but the Database Tool as described in link above took couple of minutes to create the database. Is database creation in Oracle this much slower?
Searching more about it, I have a feeling that this database created using above tool in Oracle is not equivalent to the database we create in SQL Server. Rather, the schema/user in oracle is appearing to be equivalent to database in SQL Server. Is it true?
So, If I want multiple databases in Oracle, do I create a single database and then multiple schemas inside that single database? And then are those multiple Schemas are my databases?
I am very much confused about all this. Can someone please refer me to a nice article/book that explains these things in oracle in detail?
For most purposes, yes you would indeed map a SQL server database to an Oracle schema (=user).
The term "database" in Oracle does not mean the same as in SQL Server. An Oracle "database" (from a technical point of view) is more like a SQL Server instance/installation, rather than a "database" in SQL Server.
SQL Server has two levels of namespace: database and schema. Whereas Oracle only has a single level of namespaces: a schema (which has a 1:1 relation to a user)
SQL Server and Oracle both support Schema.
A Schema is like a new database but it is not a new database
Maybe you are confused, Mysql doesn't support schemas but SQL server offers full support for it.
In mysql your database is a schema, to only difference is that it doesn't support multi schemas
For the part of creating multi databases or a single database if multiple schemas it all depend in your specific situation, you should test thinks like performance and how much money you want to spend, a multi database approach can be very expensive unlike a multi Schema approach
Is it possible to access a SQLite database running on a WP8 app from a Windows 8/Store/"Metro" app?
If yes, how - is there any trick to it? Is it easy, tricky, or impossible?
If impossible, is it possible with any other DB? AFAIK, SQLite is the only DB that can be used with the new Windows Store style sandboxed apps.
Have a look at this article. It explains that:
sqlite is only used for storing data locally (i.e. cache something from a remote data source)
you cannot connect to remote databases because that involves distributing your database connection string (i.e. username and password) to potentially millions of users
the correct way to provide data to your app is through some sort of service. Think about the different APIs major website have now.
So to answer your question: no, this is a bad idea.
I have two windows applications which will be accessing same database(stored in a hard disk). Only one of these two application is performing both read/write operations in this db while the second one only performs read operations. Do I need mutex/events to protect my db while both applications are accessing it? I was reading FAQ of SQLite which says that I might not need any resource protection, SQLite has in-built feature..
I've always personally used dedicated servers and VPS so I have full control over my SQL Server (using 2008 R2). Now I'm working on a asp.net project that could be deployed in a shared hosting environment which I have little experience with. My question is are there limitations on the features of SQL Server I can use in a shared environment?
For example, if I design my database to use views, stored procedures, user defined functions and triggers, will my end user be able to use them in shared hosting? Do hosts typically provide access to these and are they difficult to use?
If so, I assume the host will give a user his login, and he can use tools like management studios to operate within his own DB as if it were his own server? If I provide scripts to install these, will they run on the user's credential within his database?
All database objects are available. It includes tables, views, sp, functions, keys, certificates...
Usually CLR and FTS are disabled.
At last, you will not be able to access most of the server objects (logins, server trigger, backup devices, linked servers etc...)
SQL Mail, Reporting Services are often turned off too.
Depends on how the other users are authenticated to the database, if it is one shared database for all users.
If every user on the host will recieve it's own db:
If your scripts are written in a generic way (are not bound to fixed usernames in that case for example), other users will be able to execute them on their database and will have the same functionality. (Secondary click on the db and choose task->backup for example)
You could also provide simple pure backup dumps of a freshly setup database so for other users, the setup is only one click away. Also from the beginning, you should think about how to roll out changes that need to affect every user.
One possible approach is to always supply delta scripts, no matter if you are patching errors away or adding new things.
I am using sqlite3 in a linux machine and I am getting the database without username and password. Can I set a username and password for the same?
No, sqlite3 databases are very lightweight systems. They need no server and all data is stored in one file. A username/password is not supported by the sqlite/sqlite3 package.
In order to achieve simplicity, SQLite has had to sacrifice other characteristics that some people find useful, such as high concurrency, fine-grained access control, a rich set of built-in functions, stored procedures, esoteric SQL language features, XML and/or Java extensions, tera- or peta-byte scalability, and so forth.
(sqlite, when to use)
However, since it's only a file you can encrypt the file with a password to protect your data.
SQLite doesn't have a concept of username/password. It's just a single file based database.
However, on Unix you can protect your database from other users on the same machine by setting the permissions of the database file itself.
e.g. Allow only owner access
chmod 700 /path/to/sqlitedb
If it's used in a simple web application then the web application will provide the control.
The prior answers are only partially true. You can have databases that require authentication but you'll have to compile SQLite separately from PHP.
See the SQLite User Authentication documentation for further information.
SQLite is mainly an embedded database engine, not intended to be used as a multi-user database server that would require usernames and passwords.
You can always encrypt the database file with some user-provided password/-phrase, I guess. But expecting an embedded DBMS to sport full-blown access control is too much.