ORION Access Control Model - DB Security -2nd Semester 85-86 11/31 ORION: Basic Concepts Strong Authorizations Def 1.3 The function i (s, o, a) is defined as: It means that we can decide about (s,o,a) if there exist a triple in AB which itself or derivation of the triple can say something about (s,o,a). If (s,o,a)∈AB then (the scope of (s,o,a) is).
A data access layer (DAL) in computer software, is a layer of a computer program which provides simplified access to data stored in persistent storage of some kind, such as an entity-relationaldatabase. This acronym is prevalently used in Microsoft environments.
For example, the DAL might return a reference to an object (in terms of object-oriented programming) complete with its attributes instead of a row of fields from a database table. This allows the client (or user) modules to be created with a higher level of abstraction. This kind of model could be implemented by creating a class of data access methods that directly reference a corresponding set of database stored procedures. Another implementation could potentially retrieve or write records to or from a file system. The DAL hides this complexity of the underlying data store from the external world.
For example, instead of using commands such as insert, delete, and update to access a specific table in a database, a class and a few stored procedures could be created in the database. The procedures would be called from a method inside the class, which would return an object containing the requested values. Or, the insert, delete and update commands could be executed within simple functions like registeruser or loginuser stored within the data access layer.
Also, business logic methods from an application can be mapped to the Data Access Layer. So, for example, instead of making a query into a database to fetch all users from several tables the application can call a single method from a DAL which abstracts those database calls.
Applications using a data access layer can be either database server dependent or independent. If the data access layer supports multiple database types, the application becomes able to use whatever databases the DAL can talk to. In either circumstance, having a data access layer provides a centralized location for all calls into the database, and thus makes it easier to port the application to other database systems (assuming that 100% of the database interaction is done in the DAL for a given application).
Object-Relational Mapping tools provide data layers in this fashion, following the active record model. The ORM/active-record model is popular with web frameworks.
See also[edit]
References[edit]
External links[edit]
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Data_access_layer&oldid=796489740'
I am trying to access my hosting server’s database through SQL Server Management Studio, everything till login is fine but when I use the command
use myDatabase
it gives me this error:I searched over and the hosting service providers has listed this fix for the problem.
But this is not working for me probably because it's for SQL Server Management Studio 2008 however I am using SQL Server Management Studio 2012.
Can this be a problem? And if yes than can anyone tell me its alternative in SSMS 2012?
MavenMaven5,2083030 gold badges8585 silver badges138138 bronze badges
7 Answers
Check to see if your user is mapped to the DB you are trying to log into.
ScottScott
We had the same error deploying a report to SSRS in our PROD environment. It was found the problem could even be reproduced with a “use ” statement. The solution was to re-sync the user's GUID account reference with the database in question (i.e., using 'sp_change_users_login' like you would after restoring a db). A stock (cursor driven) script to re-sync all accounts is attached:
AnonymousAnonymous
I spent quite a while wrestling with this problem and then I realized I was making a simple mistake in the fact that I had forgotten which particular database I was targeting my connection to. I was using the standard SQL Server connection window to enter the credentials:
I had to check the Connection Properties tab to verify that I was choosing the correct database to connect to. I had accidentally left the Connect to database option here set to a selection from a previous session. This is why I was unable to connect to the database I thought I was trying to connect to.
Note that you need to click the
Phil RingsmuthPhil RingsmuthOptions >>
button in order for the Connection Properties and other tabs to show up.1,06244 gold badges1414 silver badges2424 bronze badges
In my case, the message was caused by a synonym which inadvertently included the database name in the 'object name'. When I restored the database under a new name, the synonym still pointed to the old DB name. Since the user did not have permissions in the old DB, the message appeared. To fix, I dropped and recreated the synonym without qualifying the object name with the database name:
Joshua YeidelJoshua Yeidel
This worked for me:
The problem can be visualized with:
azakazak
I encountered the same error while using Server Management Objects (SMO) in vb.net (I'm sure it's the same in C#)
Techie Joe's comment on the initial post was a useful warning that in shared hosting a lot of additional things are going on. It took a little time to figure out, but the code below shows how one has to be very specific in the way they access SQL databases. The 'server principal...' error seemed to show up whenever the SMO calls were not precisely specific in the shared hosting environment.
![Security Security](/uploads/1/2/5/2/125206114/154897837.jpg)
This first section of code was against a local SQL Express server and relied on simple Windows Authentication. All the code used in these samples are based on the SMO tutorial by Robert Kanasz in this Code Project website article:
The code above finds the .mdf files for every database on the local SQLEXPRESS server just fine because authentication is handled by Windows and it is broad across all the databases.
In the following code there are 2 sections iterating for the .mdf files. In this case only the first iteration looking for a filegroup works, and it only finds a single file because the connection is to only a single database in the shared hosting environment.
The second iteration, which is a copy of the iteration that worked above, chokes immediately because the way it is written it tries to access the 1st database in the shared environment, which is not the one to which the User ID/Password apply, so the SQL server returns an authorization error in the form of the 'server principal...' error.
In that second iteration loop, the code compiles fine, but because SMO wasn't setup to access precisely the correct database with the precise syntax, that attempt fails.
As I'm just learning SMO I thought other newbies might appreciate knowing there's also a more simple explanation for this error - we just coded it wrong.
AlanAlan74111 gold badge1414 silver badges2929 bronze badges
We had the same error even though the user was properly mapped to the login.
After trying to delete the user it was discovered that a few SPs contained 'with execute as' that user.
The issue was solved by dropping those SPs, dropping the user, recreating the user linked to login, and recreating the SPs.
Possibly it got in this state from restoring from backup (during a time when the related login didn't exist) or bulk schema syncing (if its possible to create an SP with execute as even though the user doesn't exist. Could also have been related to this answer.
crokusekcrokusek3,30511 gold badge2929 silver badges4949 bronze badges