I would like to track changes on views data. I don't think it is possible out of the box with current sql server change tracking. Has anyone come up with a solution to this one?
//edit
I'm synchronizing data between two databases. Synchronization works mostly on views (some tables too), so I need to track changes that are being made on views data (insert/update/delete). The task is not trivial, because some views are just JOINS and others use PIVOT.
No. No, you cannot. I wish you could.
You can track changes with DDL Triggers.. Seems like these work on SQL Server version 2005 and above.
One benefit is for users that are just not going to use source control (It happens). This can be a problem if the use GUI view creating and don't want to export to the actual text.
This records the previous versions (you already have the current in the database itself) without any user involvement.
This would free you up from having to be the bottle neck and approve or apply every change.
I didn't read enough of this to see if it would capture the user who submitted the change.
Manage the changes in your source control server and generate your views WITH ENCRYPTION so people don't mess with them on the server.
Related
A client has one of my company's applications which points to a specific database and tables within the database on their server. We need to update the data several times a day. We don't want to update the tables that the users are looking at in live sessions. We want to refresh the data on the side and then flip which database/tables the users are accessing.
What is the accepted way of doing this? Do we have two databases and rename the databases? Do we put the data into separate tables, then rename the tables? Are there other approaches that we can take?
Based on the information you have provided, I believe your best bet would be partition switching. I've included a couple links for you to check out because it's much easier to direct you to a source that already explains it well. There are several approaches with partition switching you can take.
Links: Microsoft and Catherin Wilhelmsen blog
Hope this helps!
I think I understand what you're saying: if the user is on a screen you don't want the screen updating with new information while they're viewing it, only update when they pull a new screen after the new data has been loaded? Correct me if I'm wrong. And Mike's question is also a good one, how is this data being fed to the users? Possibly there's a way to pause that or something while the new data is being loaded. There are more elegant ways to load data like possibly partitioning the table, using a staging table, replication, have the users view snapshots, etc. But we need to know what you mean by 'live sessions'.
Edit: with the additional information you've given me, partition switching could be the answer. The process takes virtually no time, it just changes the pointers from the old records to the new ones. Only issue is you have to partition on something patitionable, like a date or timestamp, to differentiate old and new data. It's also an Enterprise-Edition feature and I'm not sure what version you're running.
Possibly a better thing to look at is Read Committed Snapshot Isolation. It will ensure that your users only look at the new data after it's committed; it provides a transaction-level consistent view of the data and has minimal concurrency issues, though there is more overhead in TempDB. Here are some resources for more research:
http://www.databasejournal.com/features/mssql/snapshot-isolation-level-in-sql-server-what-why-and-how-part-1.html
https://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110).aspx
Hope this helps and good luck!
The question details are a little vague so to clarify:
What is a live session? Is it a session in the application itself (with app code managing it's own connections to the database) or is it a low level connection per user/session situation? Are users just running reports or active reading/writing from the database during the session? When is a session over and how do you know?
Some options:
1) Pull all the data into the client for the entire session.
2) Use read committed or partitions as mentioned in other answers (however requires careful setup for your queries and increases requirements for the database)
3) Use replica database for all queries, pause/resume replication when necessary (updating data should be faster than your process but it still might take a while depending on volume and complexity)
4) Use replica database and automate a backup/restore from the master (this might be the quickest depending on the overall size of your database)
5) Use multiple replica databases with replication or backup/restore and then switch the connection string (this allows you to update the master constantly and then update a replica and switch over at a certain predictable time)
We are currently working in a Healthcare application. Since medical data are very sensitive , we may have to keep history of all changes made to some medical records. I know that we can do this by keeping history tables for logging in the changes. But keeping history tables will cause the database to grow large. So I wonder if there is any features in SQL Server to track the complete data changes of a table. I have heard about Change Data Capture feature.Is it applicable in my scenario ??
Thanks in advance
It depends greatly on what you need to track. First of all, anything that tracks all history will use lots more space, and assuming the same level of detail, will not differ significantly in his much space it needs. Data is data, and it just takes space to store. However, with severally of your options you could look at storing your audit info outside of SQL if you wanted, and that helped.
Second, you have at least three immediately obvious options.
Use SQL Triggers on tables to create history tables. This does allow you to include as many, or as few columns as you want, so that is one nice feature.
Use SQL Change Tracking to monitor for changes and create history tables or otherwise audit the changes. Change tracking just stores that there were changes, it is up to you to store what the change was. Since this is queryable you can store it relatively easily outside the dB if desired.
Use SQL Change Data Capture as mentioned. This is really heavyweight, and has performance and storage implications. However, it will do most of the work for you, and is relatively easy to use.
I work as a scm developer and I am currently tasked with a activity to which involves the database versioning. Although I have done source code management I am quite new to this. Hence I would like to have different views and experience on how to implement this.
What I mean by database(oracle/sybase) version is to capture the changes which happens to the database schema/triggers/etc and store it as revisions. Basically in our company there are some changes in the customer databases which we are not aware of or at least not able to identify when and who made a particular change. We are just trying to create a record of the changes which happens in the DB.
Note: I am not a DB guy.
The usual practice is to allow changes to go through a build process. Basically.. have a version control tool like CVS where users check in the changes that have to to go to the QA and Prod environments.
So.. let's say, there are a couple of columns added to a table, the developer would check in a .ddl script with the "Alter table ..." command and that will be "applied" to the database the next time you do a build.
Unless you restrict users (in this case.. Developers) from directly making changes and instead use a standard build-process, tracking changes to objects is almost impossible over time.
Consider necessary details like the user who made the change, Time of change, reason (Check-in comments, bug Number, new feature request etc) which you'd need later to understand why a change was made. All the changes are usually compiled using a standard user like "APPOWNER" and in the absence of a version control system, you only have access to the latest change (last_ddl_change ).
If your concern is to track changes to Data, you can use triggers or use an application like Golden Gate that will read through the redo-logs and get you the change capture records. From your Question, it looks like you are looking for a way to track object changes.
The best way to do it is to have some kind of db revision software which manages all changes and allows to easily apply it to multiple databases (up/downgrade).
It requires to save all changes to revision software, no direct db changes.
Maybe similar tools for PostgreSQL will help:
depesz scripts http://www.depesz.com/index.php/projects/.
Python tool: https://code.google.com/p/sqlalchemy-migrate/
I'm making a VB.NET application with an SQL Server 2005 in the background. Naturally the user can not edit the database directly but will use a number of UI features to be able to add and modify the data.
However, there are a few tables that should be easily accessible from the admin interface such as specific information about a vendor. What's the easiest way to let the user edit this data freely? One way would be to use a DataGridView but this could appear complicated to the user, plus I'm not sure exactly when to save the edited data back to the database.
The best way that I can think of is to create custom dialog boxes for adding, deleting and changing the information, but this seems like too much work for such a small feature.
You are either going to have to give them the data in a table format (like with the DataGridView) or you are going to need to build something that lets them edit individual records (like custom forms). It seems like a lot of work (and it can be) but there are some ways to cut down on the amount of work.
Check out how to use databinding in VB.NET. There's a tutorial here, another one here and many others out there. You can use databinding for both a table view or for individual records. Using a DataGridView isn't too complicated for a user as long as you build in the necessary support in code - make sure the row is saved if it has been changed and they move to another row (or prompt them), disable editing on columns that they shouldn't be able to change, validate the data before writing it back to the database, etc.
There are also code-generation tools like CodeSmith that can create a data access layer between the GUI and the database. Some of the templates you can get will even generate the actual forms for you.
The only other option I can think of is to give them direct access to the database through tools like SQL Server Management Studio and setting up logins that only have permission to specific tables/views but I would STRONGLY recommend against that.
I have really odd user requirement. I have tried to explain to them there are much better ways of supporting their business process and they don't want to hear it. I am tempted to walk away but I first want to see if maybe there is another way.
Is there any way that I can lock a whole database as opposed to row-lock or table-lock. I know I can perhaps put the database into single-user mode but that means only one person can use it at a time. I would like many people to be able to read at a time but only one person to be able to write to it at a time.
They are trying to do some really odd data migration.
What do you want to achieve?
Do you want to make the whole database read-only? You can definitely do that
Do you want to prevent any new clients from connecting to the database? You can definitely do that too
But there's really no concept of a "database lock" in terms of only ever allowing one person to use the database. At least not in SQL Server, not that I'm aware of. What good would that make you, anyway?
If you want to do data migration out of this database, then setting the database into read-only mode (or creating a snapshot copy of it) will probably be sufficient and the easiest way to go.
UPDATE: for the scenario you mention (grab the data for people with laptops, and then re-syncronize), you should definitely check out ADO.NET Sync Services - that's exactly what it's made for!
Even if you can't use ADO.NET Sync Services, you should still be able to selectively and intelligently update your central database with the changes from laptops without locking the entire database. SQL Server has several methods to update rows even while the database is in use - there's really no need to completely lock the whole database just to update a few rows!
For instance: you should have a TIMESTAMP (or ROWVERSION) column on each of your data tables, which would easily allow you to see if any changes have occured at all. If the TIMESTAMP field (which is really just a counter - it has nothing to do with date or time) has not changed, the row has not changed and thus doesn't need to be considered for an update.