I have a JBoss application that I copied from our production system running in local. This application connects to a SQL server database. I copied also this database in local and can browse it with MS SQL server studio. After a long fight with the users and TCP connections settings in the SQL server. Now I can see how the connection between the JBoss and my copy of the DB is done in local.
However, the problem I am facing is that I get lots of exceptions like
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Invalid
object name 'table_name'.
Obviously the table_name exists in the SQL database as I can browse it, from SQL studio, using the same user JBoss is using to connect. One interesting thing is that when I browse the tables I see their names are in the form of: 'schemaName.table_name' so my only guess is that the schema is expected for the queries sent from JBoss. This is perhaps a problem with the configuration in the SQL because the JBoss is the same, the jars in the JBoss are also the same and the only thing that may be different is the creation of the users for the SQL database.
Does any one in the forum has any idea about what the problem could be or how can I specify the default schema for a certain user, so it is used in the JDBC connection?
To assign a user a default schema:
In SQL Server Management Studio go to Security / Logins / YourUser / UserMapping. There you can set the default schema for each database so you don't have to type the schema before the table names.
Related
We are attempting to join a newly configured AD FS node into the existing farm. We have tested and confirmed firewall > user access is working fine. When trying to join via the wizard we specify the existing farm server, certificate (has been imported and shows in dropdown list) and service account successfully. It fails with an error:
Multiple valid AD FS configuration databases found in remote SQL Server instance with connection string 'Data Source=REDACTED;Initial Catalog=ADFSConfigurationV3;Integrated Security=True;Min Pool Size=20'. Provide a specific database version when joining the machine.
We attempt to use the script that the wizard creates via an admin powershell and are presented with the same message. I have looked at the SQLConnectionString parameters and cannot see any that would look to specify versions from https://learn.microsoft.com/en-us/dotnet/api/system.data.sqlclient.sqlconnection.connectionstring?view=netframework-4.8#remarks
On the SQL server side, there is indeed an older database named AdfsConfiguration which has not been edited since 2020-09-06 by checking tables > IdentityServerPolicy.FarmNodes > right click > select top 1000 rows and viewing the Heartbeat property value. On the newer AdfsConfigurationV3 database under the same table and object I see modified 2022-03-30 (today).
How would I go about finding the multiple configuration databases and specifying exactly which to use? Is it safe to detach the AdfsConfiguration database or is this still used/in use by ADFS even with the later 2016 V3 present in a separate database?
• As you have stated that the ADFS server to be added in the farm is running on Windows Server 2016, the FBL (Farm Behaviour Level) version is 3 and the corresponding ADFS Configuration Database Name will be ‘AdfsConfigurationV3’. Thus, the actual databases to be searched for while specifying the configuration database should be ‘AdfsConfigurationV3’.
• If the OS version of the ADFS node server is ‘Windows Server 2012 R2’, then the FBL will be ‘1’ and the ADFS Configuration Database name will be ‘AdfsConfiguration’ while the OS version, if it is ‘Windows Server 2019’, then the FBL will be ‘4’ and ADFS Configuration Database name will be ‘AdfsConfigurationV4’. Also, you should check for the ‘AdfsConfigurationV3.mdf’, ‘AdfsConfigurationV3_log.ldf’, ‘AdfsArtifactStore.mdf’ and ‘AdfsArtifactStore.ldf’ database files in the other ADFS Farm connected servers and accordingly try to form the connection string and connect to the right database.
• It is safe to detach the ADFS database through the SQL query from the original ADFS Server by using the queries below and then copying them and pasting them at a location where SQL databases are stored on the destination ADFS Server.
USE [master]
GO
EXEC master.dbo.sp_detach_db #dbname = N'AdfsArtifactStore'
GO
EXEC master.dbo.sp_detach_db #dbname = N'AdfsConfigurationV3'
GO
Once the ADFS databases are detached using the above query and pasted on the destination ADFS Server, execute the below SQL query to attach the copied databases to the ADFS Server and make it operational.
GO
CREATE DATABASE [AdfsConfigurationV3] ON
( FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\AdfsConfigurationV3.mdf' ),
( FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\AdfsConfigurationV3_log.ldf' )
FOR ATTACH
GO
USE [master]
GO
CREATE DATABASE [AdfsArtifactStore] ON
( FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\AdfsArtifactStore.mdf' ),
( FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\AdfsArtifactStore_log.ldf' )
FOR ATTACH
GO
ALTER DATABASE AdfsConfigurationV3 set enable_broker with rollback immediate
GO
Thus, in this way, you can detach and attach the latest ADFS Database to the preferred primary ADFS Server for it to be replicated and used. But for this, please ensure that you have the ‘OWNER’ permissions access to the ADFS databases in the original and the destination ADFS Servers respectively and while performing the above tasks, ensure that the ADFS Service is stopped and started only when the operation is complete. Post completion of the above tasks, ensure that the connection to the SQL Servers is possible by referring to the documentation link below: -
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-sql
Also, refer to the link below for detailed information on the above: -
https://purple.telstra.com.au/blog/windows-server-2012-r2-adfs-3-0-migrating-adfs-configuration-database-from-wid-to-sql
Though the above link may not be discussing the issue that you are facing, but it resolves your queries to a greater extent.
I have an application which is accessing sql objects(stored procs/tables) etc which are defined under a schema 'A' for example A.my_stored_proc.
This application is working fine as intended when I connect it with the test server database. But, now as the client has asked to copy the db to into a local sql server dev edition for further enhancements.
I took backup of the db from the test server and restored it back to dev system. Now when I change the connection string of the application, the application throws an error saying that unable to located 'A.my_stored_proc'
I decided to manually test all the schema, user roles and rights against the test server which I found all are same.
For testing purpose I renamed the stored proc with 'dbo' schema and the application started working.
Can someone help me with this problem of schema with sql server 2008 r2?
On the test server, the user account under which you application works probably has A as its default schema, yet the procedure is called without schema name mentioned:
exec my_stored_proc;
On the dev server, your user account may have dbo as its default schema (or it might be the owner of the restored database, which in this particular case will lead to the same behaviour).
Consult with SQL Profiler traces to determine how procedure calls look like, exactly.
I am in the process of moving all our SharePoint DB's from a SQL 2005 server to a new 2008 server, and after moving the config database, everything seems ok, except when I click on "Timer Job Status" (under Central Admin > Operations > Global Configuration) I receive a "Unable to connect to database. Check database connection information and make sure the database server is running." error.
I get the following entries in the log regarding this:
12/03/2010
13:51:41.80
w3wp.exe
(0x09E0)
0x09AC
Windows SharePoint Services
General
8e2r
Medium
Possible mismatch
between the reported error with code =
0x8107053b and message: "Unable to
connect to database. Check database
connection information and make sure
the database server is running." and
the returned error with code
0x81020024.
12/03/2010
13:51:45.61
OWSTIMER.EXE
(0x0744)
0x0DD8
Windows SharePoint Services
Database
6f8e
Critical
SQL Database
'SP_Test_Config' on SQL Server
instance 'test-server' not found.
Additional error information from SQL
Server is included below. Cannot open
database "SP_Test_Config" requested by
the login. The login failed.
It should be noted that in order to ensure that it was no longer using the config database on the old server, I detached the original SP_Test_Config database in SQL Management Studio.
Obviously there are still references to the old SP_Test_Config database on the old 2005 server. How do I remove these references? Or, barring that, how do I move the config database in such a way that no references to the old 2005 server will remain?
Thank you in advance!
Not really an answer, but what we ended up doing (basically start from scratch using SQL Aliases):
First, create the SQL Server alias. This will make it so if you need to move the databases again in the future, you can just migrate all the databases to the new SQL Server, and change your SQL Server alias to point at that server. This should save you a lot of trouble and heartache in the future.
Run SQL Server Client Configuration Utility at: C:\Windows\System 32\cliconfig.exe.
Under the Alias tab, create a SQL Server Alias for the new SQL Server.
Now, recreate the farm.
Run stsadm -o preparetomove on all content DB's Backup all content DB's and copy to new SQL server
Remove all servers from farm using SharePoint Configuration Wizard
Recreate farm using SharePoint Configuration Wizard with the alias of the SQL Server you created above
Recreate all web apps with temp content DB's
Run stsadm -o deletecontentdb on all temp content databases created in step 4
Run stsadm -o addcontentdb using copied production databases as content database
Troubleshoot ad nauseum
I'm trying to generate my database tables from my Entity Framework model, but I'm getting this error when I execute the generation query:
Database 'Database' does not exist. Make sure that the name is entered correctly.
I'm able to connect to the local server just fine.
My connection string, which was generated by VS when I selected 'Database.mdf':
metadata=res://*/Models.Models.csdl|res://*/Models.Models.ssdl|res://*/Models.Models.msl;provider=System.Data.SqlClient;provider connection string="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\Database.mdf;Integrated Security=True;User Instance=True"
The database definitely exists, but I've noticed that the only databases it's picking up on the server are called master, model, msdb and tempdb.
Can anyone help?
Edit: I've just realised that the SQL connection dialog that comes up when you click "Execute SQL" allows you to connect to a server. But my DB isn't on a server, it's just a user instance database. But that's the only option, so how would I execute against my database? I have the database open in the 'Server Explorer'.
The connection string is referring to a user instance database is that what you intended? I got the impression possibly not from the question.
If not try changing it to Data Source=ServerName\InstanceName;Initial Catalog=Database;Integrated Security=True;
If you are using a user instance database, specify the full path to the location of the database with USE directive.
For example:
USE [C:\Project\Database.mdf]
GO
When connecting the server, you need to select another data source, then enter the name of the local server on which the database is located.
I can't speak for Entity Framework, but within SQL, "database" is a (very) reserved word. Try calling your database (and it's files) something else, even if just "MyDatabase".
I faced such problem when running a script in SQL Server Management Studio to do some stuff on my Local SQL Server. I noticed that the Query Window that I was running the script in was connected to a Remote SQL Server not my local machine.
I am migrating a classic ASP web app to new servers. The database back end is migrating from SQL Server 2000 to SQL Server 2008, and the app is moving from Win2000 x86 to Win2003R2 x64. I am getting the above error on every single stored procedure call within the application.
I have verified:
Yes, the SQL user is set up, using correct username and password
Yes, the SQL user has execute permissions on the stored procedures in the database
Yes, I have updated the TypeLib references to the new UUID
Yes, I have logged into the database via SSMS with the SQL user id and it can see and execute the stored procedures just fine in SSMS, but not from the web app.
Yes, the SQL user has the database set as its default database.
The most frustrating thing is it works fine on the DEV server, but not on the production server. I have gone through every IIS setting 5 or 6 times and the web app is set up precisely the same in both environments. The only difference is the database server name in the connection string (DEV vs prod)
EDIT: I have also tried pointing the prod web box at the dev database server and get the same error so I'm fairly sure the issue isn't on the database side.
Are you sure that you are really connected to the instance and database you think you are (in the App)? It only takes the wrong DB in the connection string to override the default database for the user.
Can you execute some inline SQL on the connection like:
SELECT ##SERVERNAME AS SERVERNAME
,DB_NAME() AS [DB_NAME]
,CURRENT_USER AS [CURRENT_USER]
It might be the schema. Have you set the default schema of your user in the database you are using?