I have extracted data from SQL 2012 to a new copy in SQL 2012 in same PC as well, in original database users can access website using their username and password, but when I try to use copied database, users cannot access into website.
Notes:
1- If I add a new user into copied data, it works fine. But If i try to access using extracted data, it will not work and no error shows.
2-original database connection was using server authentication and the copied database is using windows authentication. May I know what caused that and how to solve ?
Related
I am using classic asp and trying to access to a remote sql server.
Even though I am specifing which database is default, connection is trying to access another database and yes, user does not have access to it.
I double check user properties where the default database is correctly set and mapped. Here is my connecting string..
Driver={SQL Server};Server=1.1.1.1\SQL2005;Initial Catalog=DEFAULTDB;UID=XXXX;PWD=XXXX
We sorted it out. DBA told me that while using X database, the trigger is using another database too. So we had to authorize for that database and problem was solved.
Thank you for your contribution.
Ok, I am using an Access 2010 database linked to a SQL 2012 backend. All is well. I migrated using the Migration Wizard - this creates the link without using any pre-created ODBC\DSN file etc. This works great as I do not have to deploy any DSN file to users (it is used by 21 users) I have noticed that linked tables have the below in the Properties\Description:
ODBC;DRIVER=SQL Server;SERVER=XXX;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=XXX;Network=DBMSSOCN;TABLE=dbo.tblCountries
Now my problem is if I create a new table in the SQL backend, how do I link without using ODBC\DSN? How do I link so it behaves the same as when migrated?
I have tried creating a table then using the description from above and changing the table name to no avail. If I do link via ODBC to the SQL backend, link to the new table then change the ODBC to match that above, Access does not let you change the connection string?
So in summary, are you able to link to new tables in SQL server, after you have used the migration wizard to link?
THanks,
Michael
The DSN connection string is actually stored with the linked table. That's why your users can connect to the linked table without needing to set up a DSN connection.
I do very similar work on a daily basis with Microsoft Access connecting to a SQL database server. I have set up ODBC connections on my development machine, which allows me to easily list the tables available on the SQL server databases, and link to them in my Access applications. When linking to the table, I always save the connection string with the table link, so the end users never need the ODBC connection.
In a sense, you can think of your ODBC connection as a template for connecting to the database. As long as you always save the connection string with the linked table, your users won't need the DSN connection to access the database.
There are times when it is appropriate to use a DSN connection, but in my experience, I find it far more practical to just save the full connection string with the linked table and manage the links using the Linked Table Manager.
Hope that helps!
Adam
I am a bit new to this VB.NET application stuff. I currently try to develop a application using Microsoft Visual Basic. Net with Remote SQL Server 2005.
In my application include user login using Username and Password. The application will use from many branches. Every branch have their own Username and Password. I create User Master table in SQL Server Database with SLN, User_name, Password, Branch, Note fields.
Now I want to design a VB.Net Form in my application where I can get all Username and Branch login status in a DataGridView like....
Header - *Branch Username Status*
Value - Kolkata U00001 Logged
How can I get this? If any senior vb.net developer or expert solve the same i will be very thanks full to him. Thanking you.
Here is some SQL to extract the current users:
select distinct DB_NAME(dbid),loginame, dbid
FROM sys.sysprocesses
where [dbid] not in(0,1,4) -- exclude list
Note there are two levels of security in SQL Server - SQL Security and "Integrated" security. The latter uses the windows login, SQL Security is managed by you within SQL Server. It looks like you intend to add an SQL user/login named for the branch with a defined password that everyone in the branch will use. Not a great idea IMO. You can use integrated security and add each windows user to SQL server and then add the SQL users to security groups to control access to the SQL objects. This would require each user to authenticate with your windows servers first locally before they can connect to the remote server.
I'd highly recommend you upgrade to at least SQL Server 2008 R2.
I am attempting to migrate from SQL Server 2005 to SQL Server 2008. Both of these database instances are hosted on 3rd party shared servers that I do not have full permissions to. They are using mixed mode authentication.
I am running into trouble setting up the new database the same way the old one was set up. Specifically, the new web-based control panel doesn't allow a dbo to be specified when creating a new database and then when using Red Gate SQL Compare to sync up the schemas I am having problems because some objects (that don't explicitly specify dbo in the script) are being created with the prefix of the user account rather dbo.
I have poured over the documentation trying to find a way to force my login "user1" as dbo to the "db1" database. I came to the conclusion that the script should look like this:
ALTER AUTHORIZATION ON DATABASE::db1 TO user1
Before running this script, the login "user1" already exists, but is not a user for database "db1". Note I had to submit this script to the support of my hosting company in order to run it. According to the hosting company the statement successfully executes, however when I compare the databases using SQL Compare the user "user1" has not been physically added to the database like it was under SQL Server 2005. When trying to add it using the script:
CREATE USER [user1] FOR LOGIN [user1] WITH DEFAULT_SCHEMA=[dbo]
I get the error message:
"The login already has an account under a different username"
I have tried dropping all of the other users from the database, but the error message still persists - which I find odd.
While I could just fix the scripts by explicitly specifying dbo, this would inevitably be a time bomb waiting to go off because if any new script were introduced that didn't explicitly specify dbo there would be a failure during synchronization. Since some of the scripts are from 3rd parties, this is not a good solution.
So my questions: Is there another statement that I need to run in order to add "user1" to the database as a user that is dbo? Is there anything that has changed in the implementation between SQL Server 2005 and SQL Server 2008 R2 that could cause these inconsistencies?
I am unfortunately not able to test to find an answer to the second one because I don't have another SQL Server 2008 database to test with and I don't have full access to do anything I want on this one.
The old database was created through a control panel which forced dbo to be specified and the new one doesn't allow dbo to be specified when creating a database.
From what i have gathered the following should suffice.
ALTER USER [user1] WITH DEFAULT_SCHEMA=[dbo]
The create wasnt working as it already existed.
I've used the Access 2007 upsizing wizard to move my files to a SQL server. A problem I'm experiencing now is that when I try to link the tables in either Excel or Access, it requires me to create a DSN or a machine data source connection. In either case, when I do this, it makes the connection only useful on the current PC.
What I'm trying to do is create an access file and an excel file, both of which link to the newly upsized tables on the sql server, which I can distribute to users across the network (let's assume they all have sufficient user rights on the SQL server to read data).
Any suggestions?
Chuck
Use Doug Steele's code to convert your DSN's to DSN-less connect strings:
http://www.accessmvp.com/DJSteele/DSNLessLinks.html