I have a couple of questions.
1) Why cannot we see system tables (like sysobjects) under Master/Model/MSBD etc.? But we
can query. Are we basically querying the views, because as they are the main tables that
holds a value able informations?
Like "SELECT * FROM sysobjects". are we basically querying some views?
2) Why cannot we add triggers to system tables?
Thanks in advance
SQL Server 2008 system tables (http://msdn.microsoft.com/en-us/library/ms179932.aspx) have been implemented as read-only views. One cannot directly work with the data in these system tables. You can access SQL Server metadata using catalog views. Do check this link http://msdn.microsoft.com/en-us/library/ms174365.aspx
It is possible to create triggers on system tables but it is generally not recommended. Please check this http://www.sql-server-performance.com/faq/trigger_system_table_p1.aspx
cheers
Since SQL 2005 the catalog views are implemented as views declared in the Resource Database (mssqlsystemresource). Due to some special magic they appear to exist in every database.
You can always use the execution plan to see from what actual tables do these views fetch data from. The underlying tables can be accessed when you are connected with a DAC connection. Modifying the system tables in any way will mark the database and an message will be logged every time the database starts up. Modified databases are not supported by MS, so if something goes wrong you cannot ask for support.
Related
. I have two databases in same azure sql server .i want that both database interact to each other using trigger. i.e If any record is inserted in Customer table of first database the trigger gets fired and record is inserted in another database.
We had / have the same problem with triggers that we use for insert-update-delete where we write a record to Database-1 that has the primary table, but also updates Database-2 where we hold "archive" versions of the tables.
The only solution we have identified and are testing is to bring all of the tables into a single database and separate the different tables under separate database schemas in the one database.
Analysis so far of this approach looks promising.
I think what you're trying to do is not allowed in Sql Azure. From my expertise what you are trying to do is a bad practice on-premise as well (think backups-restore and availability issue scenarios).
You should move the dependency in the application and have the application update both databases, as appropriate.
Anyway, if you want to continue with this approach please take a look over Elastic Query feature: https://learn.microsoft.com/en-in/azure/sql-database/sql-database-elastic-query-overview
Please let me know if I can help with something
I am attempting to keep a table in Sql server updated from an access table. Any time a change is made in the access table I would like that change reflected in the sql server table. The two tables can be identical. I have created an ODBC connection from access to sql server and can export the table to sql server; I just don’t know what must be done to keep that table updated. Any suggestions are appreciated.
Should this be implemented from within Access or within sql server?
Can you just add the SQL Server table to the Access database as a linked table? (Useful article on how to add linked tables)? That way users (let's hope there's not many!) of the Access database are in effect editing the SQL Server table directly.
If this isn't desirable then how about creating another table in the SQL Server database, and adding this to the Access database as a linked table. Then, add a trigger so that when an insert/update/delete is made to this table the same operation is done on your main table.
I think setting up a Linked Server in SQL Server could be easier to implement than an automatic export of data from Access.
According to the MSDN page,
Many types OLE DB data sources can be configured as linked servers, including Microsoft Access and Excel.
Server-on-SQL-2005-Server/
Access has no "event" that occurs when a row is updated/inserted/deleted that I know of. as JeffO points out data macros that could do what you want.
You could also periodically synch them. There are several techniques to periodically do the synch task (SQL Server Agent, Windows Service, Windows Scheduler, a timer in an application etc.), but still have to deal with all the problems that exist with synchronization if both tables can be modified, the worst being data conflict resolution. There is no easy solution for that.
Perhaps if you explained the problem you have that you are solving with synching data in SQL server and Access someone might be able to point you in the direction of a solution that doesn't have these problems.
We maintain a generic tools database at work that contains useful stored procedures, functions, and the odd lookup table. It also contains some CLR objects which need to be included.
We have around 10 servers and want to have a copy of this database available on each instance inclusding CLR functions..
I plan to nominate one DB as the master and then replicate/logship the db to other instances on a nightly basis. I would also like to be able to kick off the replication by hand if necessary.
Any advice on how this can be achieved?
Thanks : )
I kept this thread open in hopes that someone would come up with something clever. Here's what I came up with:
1) You could implement the log shipping you're talking about and create a read-only snapshot of the log shipping target database on the non-master servers. You'd drop and re-create the snapshot every day.
2) Back up to a location that's available to all the servers and just do a straight restore every day.
I’m after a bit of advice on the best way to go about this is SQL server 2008R2 express. I have a number of applications that are in separate databases on the same server. They are all “plugins” that use a central staff/structure list that will be in a separate database. The application is in the process of being migrated from JET.
What I’m looking for is the best way of all the “plugin” databases being able to see the central database and use those tables in standard queries and views etc.
As I’m using express that rules out any replication solution and so far the only option I can think of is to use triggers or a stored procedure to “push” out all the changes to the plugins. The information needs to be populated on a near enough real time basis however the number of changes will be very small maybe up to 100 a day and the biggest table only has about 1000 rows at the moment (the staff names table).
Hopefully that will cover all everything but if anyone needs any more details then just ask
Thanks
Apologies if I've misunderstood, but from your description it sounds like all these databases are hosted on the same instance of SQL Server - it's your mention of replication that makes me uncertain.
Assuming that's the case, you should be able to replace any copies of tables from the central database which are held in the "plugin" databases with views or synonyms which reference the central tables directly, since SQL server allows you to make references between databases on the same server using three-part naming (database_name.schema_name.object_name)
For example, if each plugin db has a table StaffNames, you could replace this with a view by dropping the table, then creating a view:
drop table StaffNames
go
create view StaffNames
as
select * from <centraldbname>.<schema - probably dbo>.StaffNames
go
and your code should continue to work seamlessly, as long as permissions are set up.
Alternatively, you could replace all the references to the shared tables in the plugin databases with three-part name references to the central database, but the view method requires less work.
Is there any handy tool that can make updating tables easier? Usually I got an Excel file with the original value in one column and new value in another column. Then I write a formula in Excel to create the 'update' statement. Is there any way to simplify the updating task?
I believe the approach in SQL server 2000 and 2005 would be different, so could we discuss them both? Thanks.
In addition, these updates usually request by "non-programmer" (which means they don't understand SQL, so it may not feasible to let them do query), is there any tool that can let them update the table directly without having DBAs do this task? Also, that tool needs to limit the privilege to only modify certain tables. And better has a way rollback the change.
Create a DTS package that will import a csv file, make the updates and then archives the file. The user can drop the file in a specific folder designated for the task or this can be done by an ops person. Schedule the DTS to run every hour, day, etc.
In case your users would insist that they keep using Excel, you've got several different possibilities of getting the data transferred to SQL Server. My preferred one would be to use DTS/SSIS, as mentioned by buckbova.
However, another method is by using OPENROWSET(), which makes it possible to query your Excel file as if it was a table. I wrote a small article about it here: http://blog.hoegaerden.be/2010/03/29/retrieving-data-from-excel/
Another approach that hasn't been mentioned yet (I'm not a big fan of letting regular users edit data directly in the DB), any possibility of creating a small custom application for them?
There you go, a couple more possible solutions :-)
Valentino.
I think the best approach is to expose a view on your data accessible to users who are allowed to do updates, and set up triggers on the view to perform the actual updates on the underlying data. Restrict change to only the columns they should be changing.
This technique can work on SQL Server 2000 and 2005.
I would add audit triggers on the underlying tables so you can always track changes.
You'll have complete control, and they can connect to it with Access or whatever and perform their maintenance.
You could create some accounts in SQL Server for these users and limit their access to only certain tables and columns along with onlu select / update / insert privileges. Then you could create an access database with linked tables to these.