Our app uses migratordotnet to modify the backing SQL Server 2005 database. This works great 99% of the time but we are running into an issue. We have a client that is using and Active Directory group for sql server login and when new tables are added it creates them as Domain\login.table_name. What permissions are needed to be given to the AD group to add the tables as dbo.table_name? This does not happen in with all of our clients with similar configurations so I must be missing something.
Make sure that the default schema for that login / group is set to dbo.
Can you set the default schema for a group? I was unable to do that using the management studio. I am trying a solution now that specifies the schema "dbo.table_name"
Related
using SQL server 2014 I am able to select without specifying the schema name when it is NOT DBO.
We are now switching over to SQL 2016 and I am no longer able to select without adding the schema name?
Problem: Going back into each stored proc to add the schema name in would take a lot of time so I was wondering if it is possible to ignore the schema name somehow? I have been searching google but haven't found anything..
The procs are used in our SSRS reports, which there are over 100 and some are embedded into the reports so if there is a way to avoid having to change each one that would be great!
It seems the default schema is a property of the connecting user. Maybe you should check how the new "migrated" user has been defined.
I can't see all of the rows in the linked-server's tables. So if I run select count(*) from cmrez.dbo.reservations on the target server itself it returns 809472, but if I run the same query from a remote (linked) server I only get 78324. What's up with that!?
I seem to have come up with a solution. The target server supports mixed-mode logins, so I created a new login and I specify for the linked server to use that login and it appears to work. I don't know why I couldn't use pass-through security, but that doesn't matter as long as it works ;-).
I have database connection to database DB1. The only thing I could do - execute any t-sql statements including using stored procedures. I want to export the specific table (or even the specific rows of specific table) to my local database. As you can read abve, DBs are on diffrent servers meaning no direct connection is possible. Therefore question: Is it possible to write query that returns the other query to execute on local server and get data? Also note, that table contains BLOBs. Thanks.
If you have SQL Server Management Studio, you can use the data import function on your local database to get the data. It works as long as you have Read/Select access on the tables you are trying to copy.
If you have Visual Studio you can use the database tools in there to move data between two servers as long as you can connect to both from your workstation.
Needs Ultimate or Premium though:
http://msdn.microsoft.com/en-us/library/dd193261.aspx
RedGate has some usefull tools too:
http://www.red-gate.com/products/sql-development/sql-compare/features
Maybe you should ask at https://dba.stackexchange.com/ instead.
If you can login to the remote db (where you can only issue t-sql), you may create linked server on your local server to the remote and use it later directly in queries, like:
select * from [LinkedServerName].[DatabaseName].[SchemaName].[TableName]
I have a linked server where I can clearly see all the databases and tables, so I know the server is properly linked. However, when I try to execute a query, it says invalid object name, at the linked server's table.
The linked server is aliased as TCS, therefore, my query takes that table as
FROM [TCS].dbo.table as b
I have also tried including the database name also as FROM [TCS\db1].dbo.table.
What am I missing here?
Try including the DB name like so:
FROM [TCS].db1.dbo.table as b
I don't think you can specify the DB using a slash.
I would also check to make sure your security settings for the linked server are allowing your account to connect. This article touches on how to do that.
either:
the user (used for the link) doesn't have access to the table; Grant access;
the default DB on the server doesn't have the table. You have to change it to the relevant one or included in the db in the name: [TCS].DATABASE.dbo.table as b;
In VS2005, I am using a DLL which accesses a SQL Server. The DLL returns a SQLException
Invalid object name 'tableXYZ'
but tableXYZ is a table in the database.
Should it be looking for dbo.tableXYZ instead? Is this a permissions issue with the login being used?
This could be an issue with the owner of the tableand permissions.
for example the table owner may be dbo so the full table name will be dbo.TableXYZ The user you connect as, could be for example SQLUser may not have access to the dbo schema. So can only access tables such as SQLuser.TableXYZ
I'd check the permissions that you use to connect to the database.
Using dbo.tableXYZ makes it clearer what you want - the tableXYZ in the default dbo schema. There could be a tableXYZ in another schema, too - then SQL Server might not know which one you want.
And it could most definitely be a permissions issue. If you connect to that database in SQL SErver Mgmt Studio as that user - can you see that tableXYZ table??
UPDATE: does the DLL require a specific connection string, that you might not have copied into your calling app's app.config file?? DLL's in .NET can't really have their own mylibrary.dll.config - it will not be read by .NET by default.
you have to use the databasename in your connection-string - otherwise it would just connect und you have to use dbo.databasename.tableXYZ.
you can find the various connection-strings here
As a starting point, you could turn on an SQL Server Profiler trace, to see how the DLL is connecting to the database. e.g. you should be able to see what credentials are being used. You could also confirm to make sure the code is connecting to the right database etc.