Since I am going to ask simple question any help will be appreciated.
I went through SQL tutorial almost everything including (DDL, DML), however, now I have to design a library management application and found that I need to include security such as Administrator, Employee.
I searched the Internet and found that (DCL) is the way to do that
My question :)
1) since I am using ms access, is (DCL) option in it?if not how to apply security in ms access
Your question isn't clear as to what exactly you're trying to do.
If you have an Access DB with a connection to a SQL Server, you can run DCL commands via VBA SQL calls (not from the query window) to apply user control to the SQL Server.
However if you're asking about user control for an MS Access front-end, DCL does not apply, and furthermore, your options are very limited (if any serious level of security is required).
Friends and I use to race to see who could "hack" past MS Office security the fastest... as in, one to two minutes. Nowadays, Microsoft doesn't bother including the features.
You could try using the older .MDB file format, and applying Access User Level Security, as outlined in the Access Security FAQ: ULS was removed from the newer .ACCDB file format.
Recognize, though, that Access security definitely isn't unbreakable. If there's a need for strong security, you'd probably be better off putting your backend database into SQL Server.
(Source)
If you want to learn about Access, I'd suggest you do a couple Access tutorials (not SQL). The two are related but far from interchangeable, kind of like how VB and VBA are related but not interchangeable.
No, DCL is not an option in MS Access.
When you are researching things like this, keep in mind that a lot of generic database concepts have limited application in MS Access because MS Access does not provide many features of advanced database management systems.
If you have chosen MS Access as your platform, try to read only MS Access based sources of information, not generic database information. Otherwise you'll get confused.
Here are some examples of implementing security in MS Access
I know link based answers are not an answer but this may help
Using windows login, so no extra login is required
http://www.blueclaw-db.com/download/access_security_alternative.htm
Native MS Access security - do not use this, it's too complicated and probably not supported any more
https://www.thoughtco.com/microsoft-access-user-level-security-tutorial-1019981
Some other suggestions:
How to implement user-level security in Access 2007
Related
This is more of a "just wondering" question. Is there any way to access the Windows Indexing service database through ODBC in MS Access or SQL Server? I know there are a million recursive programming ways to traverse the file system but if I was only looking for files with a certain name I would think something as simple as "Select Fullpath from CDrive Where FileName like '%HEVC%'" would be easier and more lightweight than other methods.
I can't seem to Google this since all it does is return a million results for ODBC DSN creation.
Foreword: My focus is on other projects, but this is an interesting topic.
Microsoft uses an EDB file to provide a central Indexing Service - MSDN. Based on the Microsoft SQL Server CE engine, it is lightweight offers a number of methods for access including addition of third party file type definitions.
However, there are differences...significant ones that prevent direct translations of EDB and CEDB. Comparing EDB with SQL Server CE
As I said, there are access methods. The ODBC you were hoping for was discontinued after Windows XP.
However, Microsoft has developed two methods:
Windows Search (client side)
Microsoft Search Server Express (server side)
Both methods allow for quick file searches and likely could be integrated into whatever warehouse architecture you have through APIs, for example. However, there are limitations on methods that the links point out.
I admit I cannot give a full answer since I was learning, too, but hopefully this can point you in the right direction.
Cheers,
Actually, Found something else here:
Querying the Index with Windows Search SQL Syntax
Works like a charm, just have to get used to the special SQL syntax. Works on Windows 10, just having a problem querying a Storage Space. I'll update if I find an answer.
My question is this: Are there alternatives to ODBC that would allow us to connect our SQL Server to MS Access?
Here's the situation: My company works with a proprietary, SQL database (ProVenue) that up and decided to "no longer support ODBC" to MS Access, our front-end tool, without telling us.
We are currently migrating away from ProVenue, but in the meantime , we're stuck with a vendor, which "no longer supports" our ODBC connection(s). The vendor also has no incentive to help since we're leaving in several months.
I've devised a workaround where I manually export the ProVenue tables (ASCII), proof (yes, the export utiliy pulls unreliably), convert and upload on a daily basis into Access. That said, it is unreasonably time consuming given the number of tables. This work-around could be a full-time job.
Do you know of any alternatives?
Do NOT consider using ADP. It has been dropped from Access 2013 and hence is a technology with no future.
From what you're saying, you don't "own" your own MSSQL database - you're simply connecting to an instance that the provider manages, correct? I would guess that they've disabled ODBC connections to MSSQL because they don't like the load placed on their servers and/or that they've decided they want to change some underlying structures and don't want to have to cope with anybody whining about those changes.
That said, do they allow direct MSSQL connections? Via SQL Management Studio, for example? If so, you should be able to define an export & import process which is less buggy than theirs, and simply re-point your Access database to the local copy of data. True, this would still require some (possibly automated) import process, so you'd be out of synch with the server, but it'd give you the solution.
You might try connecting an .adp file to the server, to see if they'll still let you access things in that manner. That would possibly require significant modifications to your Access solution, but would also be a bit easier on their servers than linked tables via ODBC.
You could have a look at Access Data Projects (ADP) which are tied directly to one SQL Server database. I don't think they use ODBC at all, but they have their own limitations, and of course, aren't available in older Access versions.
I have a program written in Delphi 7, which uses a MS Access 2000 database as the backend.
I have password protected my MS ACCESS 2000 Database file (*.mdb) with a 16 character password consisting of a misture of Numeral, control, UpperCase, and LowerCase characters.
However, it looks like there are a number of programs on the market that claim that the password can be retrieved. What is the purpose of this database password if that is the case? Is there anyway to make it so it is not retrievable? Tighten the encryption so to speak?
thanks
MS Access 2010 uses better encryption and has some other features. SQL Server Compact edition gives you a lot more security but is still appropriate for a desktop app.
Otherwise, go with a server database: mysql, sql server, oracle. Most have free versions.
Is there anyway to make it so it is
not retrievable? Tighten the
encryption so to speak?
It depends; you can either change your database and look for a more secure one (e.g. MS SQL Server Compact Edition), or if you want to stay on MS Access and security of the data is important to you, go for encrypting important fields using a good encryption algorithm (e.g. AES).
If you are going to encrypt your fields, you can do it transparently in Delphi; each DB field in Delphi is derived from TField class, and has two events called OnGetText and OnSetText. OnGetText is fired every time you try to read the field's data, and OnSetText is fired every time you try to write to the field. You can encrypt a field data whenever OnSetText is fired, that way, the encrypted data will be saved in the database. On the other hand, you can decrypt a field data whenever OnGetText is fired, that way, user will always see and work with the decrypted data. The whole process would be transparent to the users.
Of course you should take note that encrypting/ decrypting fields every time they are being read or write has performance drawback depending on number of fields to be encrypted, their size, frequency of reading or writing them, and the encryption algorithm which is used. It's better you just encrypt the important fields.
Another option could be to encrypt the whole MS Access database file, and decrypt it whenever your application is connecting to it, but that way, the file is secure as long as your application is not running; once your application is running and the file is decrypted; the file is exposed to others.
What is the purpose of this database password if that is the case?
It makes people who think Access is a real database feel good about it.
Is there anyway to make it so it is not retrievable?
Stop using Access.
Tighten the encryption so to speak?
Not in Access. However, if you stop using Access and use a real database, you'll find that you can also have real security.
If security is a requirement then you should not be using a Jet database or any other file-sharing database architecture. It's as simple as that.
What is the purpose of this database
password if that is the case?
The purpose is to get people to upgrade to MS SQL Server and buy licenses for that as well. There are things MS will never fix.
On the other hand they have a free version of MS SQL Server which is not so crippled so you don't have to start paying through your nose unless your system will actually grow to need a full MS SQL Server.
However, if you develop systems like that (with no plan and not understanding limitations of the technologies you choose), you are most likely to lock yourself into proprietary features, for better or worse.
EDIT:
Here is quote directly from MS
Note Although the model and
techniques discussed in this article
enhance security, the most secure way
to help protect your Access data is to
store your tables on a server, such as
a computer running Windows SharePoint
Services 3.0 or Microsoft Office
SharePoint Server 2010.
Use crypt aes instead of standard mechanism.
I posted this question on Experts-Exchange as well. This is the kind of answer i was looking for (not critisism). Although this person eventually tells me to switch datbabases, he clearly explains why, without critisism:
DatabaseMX:
As you've discovered, there is essentially no security in an Access db password, prior to A2007. The are 1000's of tools (some free) that can immediately hack an Access password. A2007/10 is using an improved password paradigm ... it's security level is not clear yet.
"Is there anyway to make it so it is not retrievable"
No. It's only slightly better than nothing, depending on your specific environment where the mdb will be used.
"What is the purpose of this database password if that is the case? "
It was just a bad implementation. Period.
With A2003 and prior, the best you can do are a combination of the following:
1) db password
2) Add User Level Security
3) Create an MDE to protect code. But event an MDE can be hacked.
So, IF ... you really need better security, you will need to look at SQL Server or equivalent platform.
mx
My customer is a dental practice that has bought a piece of practice management software. This software was installed on their local server, including a patient database, a schedule and all manner of medical records. Now they want me to write some utilities for them that aren't provided with their package, and for this I need the ability to query this database.
I tried calling tech support of the software manufacturers (Patterson/EagleSoft), and it's difficult finding anyone who understands the technology enough to answer my questions. As far as I can tell, there's no API for their software, and understandably they're reluctant to tell me how to query the DB directly, programmatically. They do have an interactive query window, but obviously that's no good for writing automated queries. All that they would let on is that somewhere there's a SQL Server DB, but the ODBC drivers to connect to it are SQL Anywhere drivers (huh?).
So I searched around on the server and couldn't find any database files. Then I discovered that the installation creates some kind of proprietary virtual machine, which is only visible to the EagleSoft software. But while they've been very good at insulating their DB in layers of obfuscation, they have left open an ODBC driver, which is indeed an SQL Anywhere connection.
Now after that fascinating and lengthy preamble, here is my question: What queries can I run over this ODBC connection to interrogate the DB as to its structure? If it's a SQL Server DB underneath I could use the sysobjects table, but I don't fully grasp how you can use a SQL Anywhere ODBC connection to connect to a MSSQL DB. And If they were misinforming me and it really is a SQL Anywhere DB underneath, what are the queries to run to get at the DB structure?
And if there's anyone else out there who's ever succeeded in actually querying EagleSoft (or any similar proprietary package) - please tell me how you did it!
Turns out the simplest way to do it was to write a little app using OdbcDbConnection, and connect using the DSN installed with the software. It took one probing 'select * from sysobjects' to reveal that it is, indeed a MS-SQL database underneath all that, and I'm good to go from there!
I'd use a tool like squirel which is great at browsing any database to check if anyone was successful with "SQL Anywhere" this google result:
http://blog.gmane.org/gmane.comp.db.squirrel-sql.users/month=20091001
Shows that others have managed to get squirrel to do this. It's quite easy to use... assuming of course you manage to get the connection working!
A few tools that might help are SQLWorkbench and Django. I use SQLWorkbench to copy the data from the production system into a Postgres database so I can hack on it without damaging the production environment. Then I use Django's inspectdb to generate models of the database environment. From there it's easy to create 'views' into the database and templates to display exactly what I want.
UPDATE: As of Eaglesoft 19, it looks like Patterson has password protected the database and they have gone out of their way to prevent users from getting at the data without paying them for access.
UPDATE: Like I mentioned before, Eaglesoft 19 has a locked-down version of the database. For read-only access you can call Patterson and ask them for the password to the "Database Admin" section of their "Technical Reference" tool that is installed on your server. Once you are in there, there's an option to set a read-only password for access to the database. The username is 'dba' and whatever password you set. Some times it takes a bit of back-and-forth with them to give you access, but my solution was to say "We've been putting patient data into Eaglesoft for over a decade and we've always had access to the database. Now you're restricting it and telling us we have to pay for access. It sounds like you are trying to extort money by holding our data hostage. I should probably run this by our legal team."
EDIT: Nov 18 2022: You can still easily get read-only access to an Eaglesoft database in 21.20.08 (the latest version) by calling Patterson and getting the "day password" for Technical Reference. From there you can enable a read-only user. Based on some of the changes Patterson is making to their application architecture and the database, I suspect they will stop using direct connections to the database in the next year or two. When they make that change, you will only be able to access the database through their API Server. After playing "phone tag" with one of their salesbros for several weeks and doing some light social engineering, I managed to get their price list for going through the API server. It's atrocious. Most offices pay ~$500/mo to Patterson for free tech support and free upgrades. They want developers to pay nearly as much per office for access to the API. They've realized they can lock practices out of their own data and monetize it. We are working with a company that is actively developing a replacement for Eaglesoft to get away from this horrible vendor lock-in.
I have written my own PHP driven website to access and manipulate data in my eaglesoft database. You simply create odbc connection to local DNS entry and done. To see database structure you can use the technical reference included in eaglesoft or advanced query tool.
We are building an hosted application that uses MS SQL Server Analysis Services 2005 for some of the reporting, specifically OLAP cube browsing. Since it is designed to be used by very large global organizations, security is important.
It seems that Microsoft's preferred client tool for browsing OLAP cubes is Excel 2007 and the whole infrastructure is geared around Windows Integrated Authentication. We, however, are trying to build an internet-facing web application and do not want to create Windows Accounts for every user.
It also seems that there are not many nice AJAXy web-based OLAP cube browsing tools (fast, drag-and-drop for dimensions, support for actions, cross-browser etc.) As an aside, we're currently using Dundas OLAP Grid but have also considered RadarCube and other more expensive commercial solutions and are still thinking of taking on CellSetGrid and developing it further - if you know of any other cheap/open solutions please let me know!
We are therefore planning on providing two modes of access to the cube data:
Through our own Web Application using one of these 3rd party Web-based OLAP browsing tools.
Direct access from Excel over HTTPS via the msmdpump.dll data pump, for when the web version is too slow/clunky or user needs more powerful analysis.
For the web app access, the connection to the SSAS data source happens from the web server so we can happily pass a CustomData item on the Connection String which indicates which user is connecting. Since we potentially have too many combinations of rights to create individual SSAS roles for, we have implemented dynamic dimension security that uses a "Cube Users" dimension in conjunction with the CustomData item from the connection string and limits the Allowed Set of various other dimension members accordingly (via other Many-to-Many dinemsion relationships with Measure Groups that contain the 'rights mapping')
See Mosha on Dimension Security:
http://www.sqljunkies.com/WebLog/mosha/archive/2004/12/16/5605.aspx
This all seems to work fine so far.
For the 'direct connection' from Excel, we set up the data pump for HTTP access
(see the MS Technet article) but have enabled anonymous access, relying again on the Connection String to control access since we don't have windows accounts.
However, in this case, the connection string is controlled by the user (we push a .odc file from the web app, but a curious user could view & change it), so we cannot rely on users to be good and keep the CustomData=grunt#corp.org from changing to CustomData=superuser#corp.org. As it turns out, this also causes the same problem with Roles, since these are also specified on the connection string if you are not using Windows Integrated Authentication.
The question therefore boils down to this: is there a way of getting basic authentication in IIS working without windows accounts in such a way that it can be used with the SSAS data pump to let SSAS know which user is connecting so that dynamic dimension security can be used successfully?
(This is my first q on StackOverflow and probably the most complicated question I've ever asked: let me know where I haven't explained myself very well and I'll attempt to clarify)
Basic authentication will work with local user accounts (non-domain) and even support passthrough authentication if the local accounts exist on different machines, however you should force SSL as basic authentication sends passwords in plaintext.
You can use non-windows accounts with basic authentication in IIS with add-on such as http://www.codeplex.com/CustomBasicAuth, but SSAS will still need to know who that user is and as far as I know SSAS uses only Windows authentication.
For a (relatively) cheap thin client front-end for SSAS look at RSInteract. For bonus points it will also consume SSRS reports and report models.
Any attempt to use dimension security will require SSAS to be aware of the user and have their access rights available to it. I don't see any way to get around maintaining user permissions.