Apologies if this has been asked before - I couldn't find anything online.
I have some data in a couple of Excel spreadsheets that I need to clean, join, process etc. I would like to do this using SQL as the language is intuitive and easy to use. I currently have access to Oracle SQL Developer through my work computer, but it's not connected to any databases and I won't be able to do so for a while. I know that if I did have access to a database, I could simply upload the tables there, and then start working with them that way. Given that is not an option, I was wondering if there is anyway for me to create a local database just on my machine that I can upload those tables to and work with them that way?
Thanks!
Certainly. Go to Oracle Technology Network, download and install 18c Express Edition (XE). It is a lightweight database, fully operational and free to use. Make sure to read & follow installation guide.
Alternatively, go to apex.oracle.com and register (also for free). You'll get access to a database and the latest Application Express (Apex). Using its wizard, it is simple to create an application which will let you upload your files and work on them.
Also, there's Oracle Cloud Free Tier.
What would I do, if I were you? Install XE, probably.
Technically some of these other answers could work, but it sounds like you're working this as part of your job so you need to confirm a couple of things with your employer before diving in:
Most employers limit your ability to install software on your workstation or laptop. Oracle XE requires administrator privileges, so you need to confirm that your company will allow you to have that, and that they are ok with a database service running on a personal workstation. Many are not ok with that. Case in point: I do testing on my company laptop for various proof-of-concept things, but I'm not allowed to have admin privileges. I got special permission to install Oracle VirtualBox so I can work with some VMs, but that's it.
Given that you are working with company data, they may not be ok with you exporting that to a cloud service that they are not paying for (i.e. outside of their security boundary and legal oversight). If you plan to go that route, you need to make sure the company is ok with that approach too. My guess would be "not so much."
As far as creating a local database, you can't do that with Oracle without installing the software, which requires admin privileges. Also as I mentioned many companies have issues with installing software that creates network services (i.e. any database) on personal workstations because of the security implications.
Whatever you decide, just be sure what you're doing is legal with the powers that be.
Related
I have a vb.net windows form application with a database on SQL Server 2008 on the ./SQLEXPRESS instance.
I have created a setup of my project using the link below..
http://msdn.microsoft.com/en-US/library/49b92ztk(v=vs.80).aspx
When a user installs my application, the database will be available for him, and user can just export the SQL Server database.
How can I secure my database so that user shouldn't have a easily available copy of my database?
I thought of creating a new password protected server (as I have created the database in above walkthrough)... while installation of my application on user's pc, other than ./sqlexpress. And a complete copy of database used by my application will not be simply available for user to just export and get a copy of my database.
So could anyone please guide me...
The question is; how far do you want to go to protect your data?
Better protection of your data usually comes at the cost of more development time and likely less user friendliness, for example due to lower performance (encryption is not free). More complex code usually results in more support requests too.
Where the best balance is depends on your business model (if any) and on your user requirements.
Keep in mind that anything you deploy to an end-users machine is in the end vulnerable. If something is valuable enough there will be people trying to steal it.
So, you could argue that the best protection is not to deploy the data at all. You could back your end-user application with a web service and keep the data on your own server, for example in the cloud.
I've found however that you sometimes just need to trust your users. If you build a good product that makes them happy, they have no reason to steal from you. In fact, they are probably glad to pay you.
If you decide that you need to deploy the data and that you need to encrypt it, you should think about why you chose SQL Server.
What database features do you need exactly? Do you need a fullblown database server for that?
Any local admin can gain control over any SQL Server database in seconds so the built-in SQL server authentication will not bring you a lot of benefits.
You could switch to SQLServer CE and keep the database within your application. That would make the database a lot harder to access for a regular user.
If all you're doing is looking up words, you may be better off with a different storage engine like Lucene.
Lucene is actually a search engine, so it's highly optimized for matching words or parts of words.
You can run Lucene inside your .NET application so you don't even need the end-user to install SQL Server. There is a .NET version of Lucene here.
Lucene however doesn't protect your data. There's tooling available that will allow anybody to view and extract the data from the stored index files.
Since Lucene is open source though, you could extend it to support encrypted data storage (see this related question).
I am creating a 2-tier Lightswitch application which will be deployed via ClickOnce for single-user scenarios. The database schema and the data need to be protected from access by the users.
I know that this might not be perfectly possible, but are there ANY solutions to this?
We looked at a 3rd-party tool called DbDefence, and it seemed like a perfect fit, but their redistribution licensing pricing is way over our budget right now.
Much appreciated.
No, there's no way that I know of to prevent users from viewing or even fiddling with the database schema (if they're knowledgable enough). Unless you're creating the database for them, they have to have the permissions needed to be able to create the database. Plus updates (via Click-Once) would need update permissions on the tables.
The chances are, if you did find something, that it could prevent the application from working correctly anyway.
I want to install an application (ASP.Net + SQL server 2005 express) in local network of some small company for demoing it for a period of time, but I also want nobody even sysadmin have no permission on this database and any permission granting wants a secure pass that I have .
I just want my tables structure and relations and functions be hidden and encrypting the data have no advantage
I need to spend more time on this article Database Encryption in SQL Server 2008 Enterprise Edition that i found from this answer is-it-possible-to-password-protect-an-sql-server-database
but
1.I like to be sure and more clear on this because the other answer in this page says :
Yes. you can protect it from everyone
except the administrators of the
server.
2.if this is possible, the db have to be enterprise edition ?
3.is there any other possible solutions and workaround for this?
4.if I install a new instance with my own sa password , can i restrict other instances admins from attaching the mdf to their own ?
thanks in advance
These people can access your server or the SQL Server instance no matter what you do
anyone with physical access to the server
domain admins of the network
anyone with the sa password
a windows group with local admin and/or sa rights (which implies group policy etc)
You have to host your server offsite if you want no-one to get to log onto it.
It is that simple
In SQL Server, you cannot "password-protect" a database - what you can do is limit the permissions a given user or role has in your database.
You can DENY anyone access to your database - but that's a bit odd, since no one will be able to use it....
You can do all sorts of stuff to your database tables and logins - but a sysadmin will always be able to get around those things and get access to the database. As long as the sysadmin can get his hands physically on the server, I don't think there's any way to totally shut them out.
If you don't trust even your sysadmins, you have bigger problems.....
There's several different ways you could solve this problem.
Host it offsite - I think the easiest solution would just be to host it offsite. There's loads of cheap shared hosting out there which you could use.
Lock out the sysadmins from that server. Assuming you have root access and only you use/need that server you could change the root password and any other passwords on the server.
Do what you're currently doing and try to make something secure even when someone who shouldn't have access has root access to the server. This way sounds tricky and insecure even at best.
I have a contribution for (3):
I'm guessing (I might be wrong) you don't actually have sensitive information in your database, you just want to make it unfeasible for someone in the local network to use any of your stuff.
If that's the case, you could just make it harder for them to read your data by encrypting the data in the database and having your (compiled) code decrypt it before using it.
This way, any sysadmin who is just curious about the data or wants to change his hiscore to 13371337 will not want to go through the trouble of decompiling your code and/or cracking your encryption (for the duration of your demo) and your (assumed) problem will be solved.
I have no idea if this helps you at all, I guess I just want to say you might want to take a look at your problem again. Since you can't keep the sysadmins away from your stuff, you may want to take a different approach like making it less useful to them.
As discussed by the various other posters, you can't password protect a database - deny permissions - to the sysadmin. One alternative that hasn't been discussed is hosting it on a Laptop. Since this is a demo, you can host the Database and ASP.Net site on a laptop and hook that up to their Network - after Sysadmin permission of course - and have the clients test the application from your laptop.
This will allow you to protect the database from Sysadmins and provide the added benefit that if you want to allow them to see the database you can let them use your laptop and you will be there watching their actions on your database. This last benefit is something that you can't do easily with a hosted solution.
The above answers point 3. As for point 2, you will need the Enterprise Edition of SQL Server to take advantage of Transparent Data Encryption (TDE) as per the comparison link on MSDN. If you click on the Enterprise Security link at the top it will show a table explaining the different security capabilities of the different SQL Server versions and it shows that TDE is only for the Enterprise Edition.
After a couple of Google searches and a quick look at questions here, I cannot seem to find what I thought would be a cookbook answer for SQL Server permissions.
As I often see in small shops, most developers here were using an admin account for SQL Server while developing. I want to set up roles and permissions that I can assign to developers so that we can get our jobs done, but also do so with the minimum permissions required. Can anyone offer advice on what SQL Server permissions to assign?
Components:
SQL Server 2008
SQL Server Reporting Services (SSRS) 2008
SQL Server Integration Services (SSIS) 2008
Platforms:
Production
Staging/QA
Development/Integration
We are running "Mixed Mode" security because of some legacy apps and networks, but are moving to Windows Auth. I am not sure if that really affects the role set up.
I plan to set up access for Developers to Prod and Staging/QA DBs as Read-Only. However, I still want developers to retain the ability to run Profiling.
We need Deployment accounts with higher privilege levels. We are currently trying to figure out exactly what privileges we need for SSIS package deployments.
Within the Development Server, Developers need broad privileges. However, I am not sure that just making them all admins is really the best choice.
It's hard to believe that no one has published a decent example script that sets up these kinds of roles with a good set of appropriate permissions for developers and deployers.
We can probably figure this all out by locking things down and then adding permissions as we discover the need, but that will be way too big a PITA for everyone.
Can anyone point me to, or provide, a good exemplar for permissions for these kinds of roles on these kinds of platforms?
This will vary widely from company to company. The key ingredient is to lock down production so that devs cannot create or change objects. Our devs only have datareader rights on prod, nothing else. They can't even execute a stored proc unless logged into the application and using the application's permissions.
We give pretty much full rights to many developers on dev, but it might vary depending on which databases they are supposed to be developing against and which servers they are to access for the applications they support. So a dev with full access to one development server may not even have select rights on another.
By locking devs out of prod we have gained several critical things. First, there is no cowboy database development. They know they must create scripts for someone else to run and so they don't make random changes that they then forget about. This also means they are not a problem about putting the scripts into source control, since the people who do have rights to prod will only run a script if it is in Source control.
Next there are no people making on-the-fly emergency, untested changes to prod, that never get down to dev and qa and are thus lost the next time a new version is loaded up. As a result the changes that didn't work on prod have gone way down as well because now everything is tested before someone tries to put it on prod.
Nor are people making on the fly data changes to prod and accidentally updating the entire user table because they forgot to highlight a where clause (yes this happened before we locked down prod).
I've been searching for similar guidance but didn't find any. After some experimentation, I think a simple setup would be to add the user to the "dbcreator" server role, then add them to the "db_owner" role in each database they will be working on. This would allow the user to create new databases, as well as modify the ones in which they are a member of "db_owner."
We have 18 databases that should have identical schemas, but don't. In certain scenarios, a table was added to one, but not the rest. Or, certain stored procedures were required in a handful of databases, but not the others. Or, our DBA forgot to run a script to add views on all of the databases.
What is the best way to keep database schemas in sync?
For legacy fixes/cleanup, there are tools, like SQLCompare, that can generate scripts to sync databases.
For .NET shops running SQL Server, there is also the Visual Studio Database Edition, which can create change scripts for schema changes that can be checked into source control, and automatically built using your CI/build process.
SQL Compare by Red Gate is a great tool for this.
SQLCompare is the best tool that I have used for finding differences between databases and getting them synced.
To keep the databases synced up, you need to have several things in place:
1) You need policies about who can make changes to production. Generally this should only be the DBA (DBA team for larger orgs) and 1 or 2 backaps. The backups should only make changes when the DBA is out, or in an emergency. The backups should NOT be deploying on a regular basis. Set Database rights according to this policy.
2) A process and tools to manage deployment requests. Ideally you will have a development environment, a test environment, and a production environment. Developers should do initial development in the dev environment, and have changes pushed to test and production as appropriate. You will need some way of letting the DBA know when to push changes. I would NOT recommend a process where you holler to the next cube. Large orgs may have a change control committee and changes only get made once a month. Smaller companies may just have the developer request testing, and after testing is passed a request for deployment to production. One smaller company I worked for used Problem Tracker for these requests.
Use whatever works in your situation and budget, just have a process, and have tools that work for that process.
3) You said that sometimes objects only need to go to a handful of databases. With only 18 databases, probably on one server, I would recommend making each Databse match objects exactly. Only 5 DBs need usp_DoSomething? So what? Put it in every databse. This will be much easier to manage. We did it this way on a 6 server system with around 250-300 DBs. There were exceptions, but they were grouped. Databases on server C got this extra set of objects. Databases on Server L got this other set.
4) You said that sometimes the DBA forgets to deploy change scripts to all the DBs. This tells me that s/he needs tools for deploying changes. S/He is probably taking a SQL script, opening it in in Query Analyzer or Manegement Studio (or whatever you use) and manually going to each database and executing the SQL. This is not a good long term (or short term) solution. Red Gate (makers of SQLCompare above) have many great tools. MultiScript looks like it may work for deployment purposes. I worked with a DBA that wrote is own tool in SQL Server 2000 using O-SQl. It would take an SQL file and execute it on each database on the server. He had to execute it on each server, but it beat executing on each DB. I also helped write a VB.net tool that would do the same thing, except it would also go through a list of server, so it only had to be executed once.
5) Source Control. My current team doesn't use source control, and I don't have enough time to tell you how many problems this causes. If you don't have some kind of source control system, get one.
I haven't got enough reputation to comment on the above answer but the pro version of SQL Compare has a scriptable API. Given that you have to replicate stuff to all of these databases you could use this to make an automated job to either generate the change scripts or to validate that the databases are all in sync. It's also not much more expensive than the standard version.
Aside from using database comparison tools, with 18 databases you should have a DBA, so enforce a policy that only the DBA can change tables at the database level by restricting access to CREATE and ALTER to the DBA only. On both your test and live databases. The dev database shouldn't have this, of course! Make the developers who have been creating or altering the schemas willy-nilly go via the DBA.
Create a single source-controlled DDL/SQL script for each release and only use it to update the databases. The diff tools can be useful but mainly for checking that you haven't made a mistake and getting out of trouble when the policies fail. Combine the DDL, SQL, and stored procedure scripts into a single script so that it's not easy to "forget" to run one of the scripts.
We have got a tool called DB Schema Difftective that can compare and sync database schemas. With our other tool, DB MultiRun you can easily deploy generated (sync) scripts to multiple db servers (project based).
I realize this post is old, but TurnKey is correct. If you are a developer working in a team environment, the best way to maintain a database schema for a large application, is to make updates to a Master Schema in what ever source safe you use. Simply write your own Scripting class and your Database will be perfect every time.