I have a local dev copy of our production DB. However, in production, we have a DB link to a second DB, and this is not available outside of a production environment.
I'm pretty new when it comes to this kind of stuff. Would it be possible to create a second local DB to point my DB link to in Oracle SQL Developer? Or could I create a new user on my existing DB and point the DB link to that user's schema? What is the best way to go about this?
Related
We have a shiny app running from our institute server (basically modifying a table).
We would like to store the table in an SQL DB.
Is it possible to save the SQL DB in a Dropbox account and interact with it from there?
Pseudocode:
load table from Dropbox SQL db
create DT data table
modify the data table in shiny
Update the SQL DB in Dropbox
I am asking for any working examples illustrating the first and last steps above.
Many thanks!!
I'm not sure what you're referring to by "Dropbox SQL db" - does Dropbox have an own SQL service? I believe not. Do you have some kind of SQL dump in the dropbox?
Anyways, what you could do, is setting up a sqlite database and save it to the dropbox. To my knowledge, SQLite does not support concurrent connections, but if only one user is accessing the SQLite db, then it should work.
Check out RSQlite.
/Edit: Of course, the institute server also has to have direct access to the dropbox.
I have created a new Azure Database and I want to start developing against it. Is there a way to indicate that this database is a DEV only database? I do not want to get charged for it until I am ready to go to production. Is there such an option?
Additionally, a singelton Basic database starts at $5/month [link]. Combined with an Azure Free Trial [link], one can make this offer stretch quite a bit for a dev environment.
When you create new website you can also choose to create new free database for this website
I'm working on a project as an outsourcing developer where i don't have access to testing and production servers only the development environment.
To deploy changes i have to create sql scripts containing the changes to make on each server for the feature i wish to deploy.
Examples:
When i make each change on the database, i save the script to a folder, but sometimes this is not enought because i sent a script to alter a view, but forgot to include new tables that i created in another feature.
Another situation would be changing a table via SSMS GUI and forgot to create a script with the changed or new columns and later have to send a script to update the table in testing.
Since some features can be sent for testing and others straight to production (example: queries to feed excel files) its hard to keep track of what i have to send to each environment.
Since the deployment team just executes the scripts i sent them to update the database, how can i manage/ keep track of changes to sql server database without a compare tool ?
[Edit]
The current tools that i use are SSMS, VS 2008 Professional and TFS 2008.
I can tell you how we at xSQL Software do this using our tools:
deployment team has an automated process that takes a schema snapshot of the staging and production databases and dumps the snapshots nightly on a share that the development team has access to.
every morning the developers have up to date schema snapshots of the production and staging databases available. They use our Schema Compare tool to compare the dev database with the staging/production snapshot and generate the change scripts.
Note: to take the schema snapshot you can either use the Schema Compare tool or our Schema Compare SDK.
I'd say you can have a structural copy of test and production servers as additional development databases and keep in mind to always apply change when you send something.
On these databases you can establish triggers that will capture all DDL events and put them into table with getdate() attached. With that you should be able to handle changes pretty easily and some simple compare will also be easier to apply.
Look into Liquibase specially at the SQL format and see if that gives you what you want. I use it for our database and it's great.
You can store all your objects in separate scripts, but when you do a Liquibase "build" it will generate one SQL script with all your changes in it. The really important part is getting your Liquibase configuration to put the objects in the correct dependency order. That is tables get created before foreign key constraints for one example.
http://www.liquibase.org/
We create multiple databases in sql server 2005. I would like to make sure that every new database that is created has a specific read only account when it gets created. I know there is a way to write code to do this, but is there a way we can set up a database template of some sort so every time a new database is created the account is automatically added from SQL server side rather than the code side?
If you mean one read-only user account for all databases on a server, you can use this hack:
Create a new SQL Server login
Create a new Database user in model database with db_datareader privilegues.
All new databases use the model db as template, so the user will be available in all databases.
But keep the security issues in mind. ;-)
We are not hosting our databases. Right now, One person is manually creating a .bak file from the production server. The .bak then copied to each developer's pc. Is there a better apporach that would make this process easier? I am working on build project right now for our team, I am thinking about adding the .bak file into SVN so each person has the correct local version? I had tried to generate a sql script but, it has no data just the schema?
Developers can't share a single dev database?
Adding the .bak file to SVN sounds bad. That's going to keep every version of it forever - you'd be better off (in most cases) leaving it on a network share visible by all developers and letting them copy it down.
You might want to use SSIS packages to let developers make ad hoc copies of production.
You might also be interested in the Data Publishing Wizard, an open source project that lets you script databases with their data. But I'd lean towards SSIS if developers need their own copy of the database.
If the production server has online connectivity to your site you can try the method called "log shipping".
This entails creating a baseline copy of your production database, then taking chunks of the transaction log written on the production server and applying the (actions contained in) the log chunks to your copy. This ensures that after a certain delay your backup database will be in the same state as the production database.
Detailed information can be found here: http://msdn.microsoft.com/en-us/library/ms187103.aspx
As you mentioned SQL 2008 among the tags: as far as I remember SQL2008 has some kind of automatism to set this up.
You can create a schedule back up and restore
You don't have to developer PC for backup, coz. SQL server has it's own back up folder you can use it.
Also you can have restore script generated for each PC from one location, if the developer want to hold the database in their local system.
RESTORE DATABASE [xxxdb] FROM
DISK = N'\xxxx\xxx\xxx\xxxx.bak'
WITH FILE = 1, NOUNLOAD, REPLACE, STATS = 10
GO
Check out SQL Source Control from RedGate, it can be used to keep schema and data in sync with a source control repository (docs say supports SVN). It supports the datbase on a centrally deployed server, or many developer machines as well.
Scripting out the data probably won't be a fun time for everyone depending on how much data there is, but you can also select which tables you're going to do (like lookups) and populate any larger business entity tables using SSIS (or data generator for testing).