For a project I am currently working on, I am required to use triggers to restrict users' access to a database. However, since there are no triggers on SELECT statements, I need to find some alternative method for adding restrictions before a SELECT statement is executed. Are there any alternatives to "Triggers on SELECT"? if so, what are they?
Note: This is an assignment, thus I cannot add the restrictions at application level since the point of the assignment is to add restrictions at the DB Level.
I have also read all other posts that I can find on this, please don't close this post pointing me to some other related posts unless they have several alternatives I can choose from. I'm not saying these posts are of no use or the solutions are not proper, However, I would like to explore all of the possible solutions.
One solution is to change the table to a view, such that querying the view invokes a stored function, and the stored function logs access to the table.
Here's a blog by the great Roland Bouman, describing the process in detail:
http://rpbouman.blogspot.com/2005/08/mysql-create-dirty-little-tricker-for.html
Related
I'm looking for a PHP script that will allow me to easily manage 'MySql' tables. By managing I mean not their creation but the possibility of adding new records, modifying and deleting them.
It must be possible to specify for each user which tables he will have access to and with which modalities (insertion only, modification only, etc.).
For each user I will also have to specify whether he will be able to see all or some of the columns in the table and with which permissions.
Also I'll need to know who did what, a sort of global change LOG.
My idea was to have a back-end in which I specified the users and how to access the various tables/columns and a front-end for the users.
In the front-end users will be able to add/modify/delete records and data they are allowed and the ability to filter and/or sort the various records.
I know I could use some PHP frameworks or rely on CMS but I have to write a lot of code by hand and it seems hardly credible that such a product is not already available.
Does anyone know if there is something like this?
I had tried starting with PHP frameworks but implementing everything from scratch stopped me.
I expect there is already something available.
Thanks.
Davide.
I have reviewed the previous Questions and haven't found the answer to the following question,
Is there a Database Tool available in MS Access to run and identify the Queries that are NOT Bring used as a part of my database. We have lots of Queries that are no longer used and I need to clean the database and get rid of these Queries.
Access does have a built in “dependency” feature. The result is a VERY nice tree-view of those dependencies, and you can even launch such objects using that treeview of your application to “navigate” the application so to speak.
The option is found under database tools and is appropriately called Object Dependencies.
The result looks like this:
While you don't want to use auto correct, this feature will force on track changes. If this is a large application, then on first run a significant delay will occur. After that, the results can be viewed instantly. So, most developers still turn off track name autocorrect (often referred to track auto destroy). However, the track auto correct is required for this feature.
And, unfortunately, you have to go query by query, but at least it will display dependences for each query - (forms, or reports). However, VBA code that creates SQL on the fly and uses such queries? Well, it will not catch that case. So, at the end of the day, deleting a query may well still be used in code, and if that code creates SQL on the fly (as at LOT of VBA code does, then you can never really be sure that the query is not not used some place in the application.
So, the dependency checker can easy determine if another query, another form/sub form, or report uses that query. So dependency checker does a rather nice job.
However, VBA code is a different matter, and how VBA code runs and does things cannot be determined until such time code is actually run. In effect, a dependency checker would have to actually run the VBA code, and even then, sometimes code will make several choices as to which query to run, or use - and that is determined by code. I suppose that you could do a quick "search", since a search is global for VBA (all code in modules, reports and forms can be searched). This would find most uses of the query, but not in all cases since as noted VBA code often can and does create sql on the fly.
I have a vague recollection part of Access Analyzer from FMS Inc has this functionality built in.
Failing that, I can see 2 options that may work.
Firstly, you could use the inbuilt Database Documenter. This creates a report that you can export to Excel. You would then need to import this into the database, and write some code that loops the queries to see if they appear in this table;
Alternatively, you could use the undocumented "SaveAsText" feature to loop all Forms/Reports/Macros/Modules in your database, as well as looping the Querydefs and saving their SQL into a text file. You would then write some VBA to loop the queries, open each of the text files and check for the existence of the query.
Either way, rather than just deleting any unused queries, rename then to something like "old_Query", and leave them for a month or so in the database just in case!!
Regards,
I want to create an insert trigger on MySQL which will automatically insert the record into an Oracle database. I would like to know if there are people that have experience to share on this topic.
Cheers
Invoke a script as is done in this example that calls the Oracle code.
Note: you lose support for transactions (there will be no built-in rollback for the Oracle database) when you perform this type of cascading, and you also will take a likely very large performance hit in doing so. The script could turn around and simply call Java code or some other executable that invokes your some generic code to insert into Oracle, or it could be a raw query that gets passed arguments from the script.
This is almost certainly a bad idea because of the odd side-effect behavior, but it's one that can be implemented. I think that you would be much better off having the code to do this against two different DataSources (in Java/.NET speak) rather than have a hidden script in a MySQL trigger that screams unmaintainable, as well as hidden failure for future developers.
I am learning Devart's mydac Data Access Components and I have few question I have not been able to resolve through online searches and the documentations. In the code examples, I see invocation of TMyTable.Open but I could not find the description in TMyTable class or its inheritance path. I would like to as if anyone can point me to the documentation of this method and whether it has any relationship to TDBGrid class.
Thanks in advance
TDataSet.Open is generally used to get a data cursor back from the database.
In order to use a TDBGrid you need to connect it to the TDataSet (In your case a TMyTable) through a TDataSource.
On the other hand TMyTable.Execute will only run your SQL code on the server and not retrieve any data (except for some info on the affected rows).
You normally use Execute for INSERT, DELETE, UPDATE, etc and Open for SELECT statements.
In my case, a F1 keystroke while the caret is over a SQLQuery1.Open; brings the help in the DB.TDataSet.Open article, which in turn gave me a (broken) link to the current DocWiki Page. Far from perfect, but good enough to get basic information.
http://docwiki.embarcadero.com/VCL/en/DB.TDataSet.Open
I'm not even sure SQL Server stores this kind of information, but, is it possible to get the username of the person who last modified a particular stored procedure, function, table or view?
Nothing critical, just wondering. Thanks!
If you are using SQL Server 2008, you could use some new features that allow you to put triggers on DDL changes. You can then track, based on the authenticated user, who made the change.
I think these triggers are new to SQL 2008, but they may be available in 2005.
Having said this, ideally you should have your database schema under source control, using a tool like Visual Studio Database Professional. Then you'd have a complete history of who did what and when.
Randy
It doesn't store this information out of the box.
You can use SQL Trace and Event notification (see the corresponding MSDN Article) to log this kind of information by yourself.
I have no experience with these technologies though ...
Definitely put DDL triggers in place. Even if you don't end up using them, or if you end up putting a decent source control system in place, still have the DDL triggers in place so that you can be sure about what's going on.