Am using grids in VB.net to display database records stored in Microsoft Access, the tables allow editing and deleting using the grid fields.
Is there a way I can monitor whenever a user deletes or edits a record? I want to be able to view details of every update or deletion to certain records, such as the date and users who did it.
What you're speaking of is known as "auditing" and certain databases - such as MS SQL Server - have built-in support for this. MS Access does not include this feature. With the abscence of auditing, a common way to implement this in a custom manner is using update triggers. Unfortunately MS Access also does not have triggers. The only way you'll be able to do this is via an API you write yourself to interact with your tables and discipline to stick to that API.
What you want to do is hook into the save commands on your inserts and deletes. You could also hook into the events to capture the data. Either way, create an insert statement that dumps the log data into your log database.
Related
in the project i am working on, we have a database per tenant and each tenant consists of at least 1 department. One of the requirements we have is that when an admin user deletes a department using a custom frontend we've provided, the system should first archive the data of that department on a blob storage before the data is deleted. The same we have for the tenant, we need to archive the data before the database of that tenant is removed from the account.
Now, my question: is there any best practice to do this? We are planning to retrieve all the data from all collections, using a mongo query, based on the department id (which is also the partition key) and then send it to a blob storage. The challenge we have is the execution of the query to retrieve all the data because it can be a huge amount and the RUs required for that action may affect the performance of the system because other users may be using the system while we remove the data.
I looked at mongodump and mongoexport but these are applications so we cannot execute it from our code?
Any ideas? Thanks a lot.
I think one way to solve this is by using ChangeFeed, as it reallyhelps and simplifies writing a carbon copy somewhere else.
However, as of now the change feed processor won't notify you for deleted documents so you can't listen for them, this feature is planned as of now.
Your best bet is to write some custom application that does archiving using Query language support
For history, I just recently wrote this question:
This has led to a follow up question. In the User Profile, "Roles" Tab (which I'm assuming is a table somewhere), is there a table I can report on that will get me what was changed and possibly by which user account (and maybe even the IP address of the user account)?
The path is:
Main Menu->PeopleTools->Security->User Profiles (and then the 'Roles' Tab).
Ultimately I need to figure out what change was made (when a role name was added) and by what user account and as of what date/time. If possible I need to link it to the IP address (which I think is found here: PSACCESSLOG).
what you need is audit on the PSROLEUSER table: you need to build an audit table for it and fill it either by a database trigger or through a PeopleSoft development: adding record audit to the PSROLEUSER table.
The PSROLEUSER table stores the roles a user is assigned. By default there is no history. To get that you would need to enable auditing, either record auditing through App Designer or setting up database trigger auditing. The database trigger audits can actually capture changes made either online or through the database so could be considered more complete, but can take some effort to get working properly. However, the database triggers also allow capturing some additional user information at the time of the transaction.
See http://peoplesoft.wikidot.com/auditing-user-profiles, particularly the section on using the the GET_PS_OPRID functions for Oracle or the SQL Server equivalent. Capturing the OSUSER and IP here would more reliable than trying to tie back to PSACCESSLOG.
I'm constructing a website.
In this website, people will be able to manipulate several DB tables data.
Everytime someone wants to make a CUD operation I want to log it (like and audit).
The way I see it, I should use triggers for CUD operations, but I can't understand how do I log the user, since triggers don't accept any input parameter.
NOTE: the user I want to log is the network user. I know this user when they access the website (user to log <> user logged to DB).
ANOTHER NOTE: None of my tables saves creation date, creator, update date and updator. Just don't know why they should when I have the audit tables.
So this is the basic problem with web apps. If you have a huge user base ( more then say 500 ), then provisioning them in the database, while this is very easily doable, it is something most web programmers, sadly, don't want to deal with and want only ONE connection user for the database. You have already shot yourself in the foot because you don't have the created_by,modified_by, created_date, modified_date in the tables. To fix this you really only have one choice:
Put the columns on the tables and force the UI people to push the "network" user name through. The rest of the columns can be handled by one very simple trigger.
Why DB audit will not help you:
The DB audit feature ONLY deals with users defined as actual users in the database, sorry that is just the way it is.
Here are some things to look at when dealing with a front end system.
You can write SP's or Packages that execute as the schema owner, but can be run by ANYONE who is defined in the database and those can handle all the INSERT, UPDATE, DELETE operations on the schema they are defined in by simply giving other users the EXECUTE privilege on that set of SP's. This give the DB fine grain control over how tables are manipulated and you only have to grans the select privilege to all the users.
You can write a SP or Package in the SYSTEM schema that allows a group of people to provision users on the system by granting the execute privilege on that SP. Within that SP you define what ROLES they are assigned and therefor can control all their access.
I am using the SqlProfileProvider to store my user profiles in an asp.net web application.
What I am looking for is a way to fetch all user profiles (I would prefer a search API, but there is not one available) with some reasonable performance.
Using the ProfileManager.GetAllProfiles kills the performance of my application.
I was thinking of using Sql Cache Dependency on the object that returns from this method, but I would still have a very slow site every time someone updates a profile (which could happen several times a day).
Anyone have a suggestion to improve the performance? I am looking for things on these lines:
Caching efficiently (only the differences should be re-cached)
Optimizing the GetAllProfiles call
Being able to search profiles, instead of having to fetch them all and filtering later
The sqlProfileProvider does not provide an easy way to search profiles as all profile data is stored in a single column.
You should consider creating your own profile provider or use something like the Table Profile Provider. This stores each profile property in its own database column and so you could easily write custom queries to search the data.
We are going to be selling a service that will be hosted by us, and each client we host will have their own database, but there will be one centralized website. I currently have a blank database with the few things that a new client will need. What is the best way to copy this database so I can setup another client? I want to be able to do this from an .aspx page. Thanks in advance!
Update:
By .aspx page, I just meant that I need to be able to kick off the process from an .aspx page.
Update2:
We're running SQL Server 2008.
Update 3: Referencing Cade Roux's answer... Thanks for a great answer, but...
What is the reason for merging all of the databases into one, and then distinguishing clients based on an identifier in each table? Wouldn't this greatly complicate the architecture of the entire product? I would need to add these Client ID columns to practically every table, and the DAL would need to know which client data its looking for. With the current setup I have, I just switch out the connection string in the DAL, depending on which user is accessing the site. That way, after the connection string is set, I never need to worry about finding client specific data! How do these approaches compare (and should I add this as a separate question?
You have a few different options:
You can detach your empty database, then when a user signs up, copy that database and mount it under a unique name for them and map it to their account in your master database, say.
You can create a database from scratch using scripts and populate any base data either from an online template database or scripting the base data and map it to their account in your master database.
You should seriously consider going to a multi-tenant architecture where all users are in the same database (with most tables having CustomerID columns to segregate the data) if you are going to have more than a few dozen customers.
Regarding your notes about option 3 - it depends on your application. Multi-tenant can be difficult to retrofit. On the other hand, managing and upgrading hundreds of individual customer databases can be difficult in the long haul.
There are previous Stack Overflow questions regarding this:
What are the advantages of using a single database for EACH client?
One database or many?
I think I'll see about re-tagging them with multi-tenant-db or something. Anyhow, I think that this comes up as a consideration secondary to your answer about a particular tactic does show the importance of including details about your overall goals in strategy in every question on StackOverflow.
Depending on what database you're using, there are several approaches. The simplest is to ask your database software to generate SQL code for creating the database and include that with your software. Another would be to just script out in C#/VB the steps needed to recreate your empty database.
Why the need for .aspx page?
You don't say what db version you're using but in SQL2005-2008, you have the ability to "script database as" and then "create to" and have it port the sql to a query window. You could then work with that to create a stored procedure that can be called from your .aspx page.
SQL Server has a system database called 'model'. Any database objects (tables, views, stored procedures) that exist in the model are added to any new database created.
You could create your 'client database' schema as model, and any new database would have all the same tables...
But, if you need to change your database schema later, your best option is to write change scripts which are part of your code-behind file. Since changes to the 'model' database are not propagated to existing databases, the application needs to detect and upgrade the database schema as necessary.
Disadvantage to this approach: If you want a database which isn't a 'client database' then you would need to create the database, and then delete the 'client database' tables.