Access To The Remote Server Is Denied Because The Current Security Context Is Not Trusted
Jun 27, 2007
I am unable to run a stored procedure that accesses a linked Oracle database as a dataset for a deployed report in Reporting Services. I receive the following error:
An error has occurred during report processing.
Query execution failed for data set 'spName'.
Access to the remote server is denied because the current security context is not trusted.
A few facts ...
The report previews fine in Microsoft Visual Studio 2005 Version 8.0.50727.762 (SP.050727-7600) report designer with VS being installed on my local machine and a shared data source referencing Server1
The deployed report on Server2 produces the error
The stored procedure code is similar to the following:
SELECT x.FieldName as OracleField
,y.FieldName as SSfield
FROM OracleLinkedServer..DatabaseName.TableName x
LEFT JOIN Server1.dbo.TableName y
The deployed report runs fine when the stored procedure code is changed as follows. This indicates to me that the problem is truly an Oracle connection issue;
SELECT 'ABC' as OracleField
,y.FieldName as SSfield
FROM Server1.dbo.TableName y
The Oracle database is a linked database on both SQL Server1 and on SQL Server2 database engines. (I don't see where in Server2 Reporting Services I can specify additional server connections.)
I've tried to trick Mr. Reporting Services on Server2 by creating a @L_TempTable in my stored procedure, inserting the data into it, then selecting from a SQL Server1.dbo.TableName LEFT JOIN @l_TempTable, but Server2 still knows I'm trying to get out to Oracle and rewards me with the error.
I can effectively run the Server1 stored procedure script on Server2 through MSSMS -- it's just the deployed report that references the stored procedure that doesn't work
The data source properties of the deployed report are as follows:
Select -- A Custom Datasource
Connection Type: Microsoft SQL Server
Connectoin String: Data Source=Server1;Initial Catalog=DatabaseName
Select -- Credentials stored securly in the report server
Username: UserName
Password: Password
Check -- Use as Windows credentials when connecting the the data source
Check -- Impersonate the authenticated user ...
(Please do not get sidetracked on the 'A Customer Datasource' selection above. I'd rather be using a shared data source, but right now, this is just the way it is.)
Anyone's expertise would be greatly appreciated. We have a great data warehouse but sometimes you just have to go back to the Oracle ERP and slug it out. What do I need to do to get a deployed report to effectively read from a stored procedure that references an Oracle table?
I am unable to run a stored procedure that accesses a linked Oracle database as a dataset for a deployed report in Reporting Services. I receive the following error:
An error has occurred during report processing.
Query execution failed for data set 'spName'.
Access to the remote server is denied because the current security context is not trusted.
A few facts ...
The report previews fine in Microsoft Visual Studio 2005 Version 8.0.50727.762 (SP.050727-7600) report designer with VS being installed on my local machine and a shared data source referencing Server1 The deployed report on Server2 produces the error The stored procedure code is similar to the following:
SELECT x.FieldName as OracleField
,y.FieldName as SSfield
FROM OracleLinkedServer..DatabaseName.TableName x
LEFT JOIN Server1.dbo.TableName y
The deployed report runs fine when the stored procedure code is changed as follows. This indicates to me that the problem is truly an Oracle connection issue;
SELECT 'ABC' as OracleField
,y.FieldName as SSfield
FROM Server1.dbo.TableName y
The Oracle database is a linked database on both SQL Server1 and on SQL Server2 database engines. (I don't see where in Server2 Reporting Services I can specify additional server connections.) I've tried to trick Mr. Reporting Services on Server2 by creating a @L_TempTable in my stored procedure, inserting the data into it, then selecting from a SQL Server1.dbo.TableName LEFT JOIN @l_TempTable, but Server2 still knows I'm trying to get out to Oracle and rewards me with the error. I can effectively run the Server1 stored procedure script on Server2 through MSSMS -- it's just the deployed report that references the stored procedure that doesn't work The data source properties of the deployed report are as follows:
Select -- A Custom Datasource
Connection Type: Microsoft SQL Server
Connectoin String: Data Source=Server1;Initial Catalog=DatabaseName
Select -- Credentials stored securly in the report server
Username: UserName
Password: Password
Check -- Use as Windows credentials when connecting the the data source
Check -- Impersonate the authenticated user ...
(Please do not get sidetracked on the 'A Customer Datasource' selection above. I'd rather be using a shared data source, but right now, this is just the way it is.)
Anyone's expertise would be greatly appreciated. We have a great data warehouse but sometimes you just have to go back to the Oracle ERP and slug it out. What do I need to do to get a deployed report to effectively read from a stored procedure that references an Oracle table?
In SQL 2005, from a stored procedure in a local database I am attempting to execute a remote stored procedure in another database on another server. I am getting the error referred to in the Subject when the local stored procedure tries to execute the remote stored procedure. A couple of comments:
The remote database is set up as a linked server in the local database. As part of the linked server definition I selected the 'be made using this security context', and provided a local user name and password. The remote database is set to Trustworthy. I have tried every combination of WITH Execute As on the remote stored procedure but nothing works. I can query against the remote database successfully within Management Studio. I can even execute the remote stored procedure successfully from within M.S., but not from within my local stored procedure when it is run.
We've got 3 SQL Servers all SQL Server 2012. We have a Master server and 2 production servers (let's call them A and B). The Master has linked servers defined for both A and B in an identical way.
A and B both have the same databases and each has a Stored Proc that gets called by the Master server. An SQL Agent job executes the stored proc on both A and B. It works fine against A but not B.
If we execute the stored proc in a query window under our windows account (domainowner) it works, if we use SetUser to pretend to be the SQL Server Agent account (let's call it domainagent) A works and B doesn't.
Executing against B returns the error "Access to the remote server is denied because the current security context is not trusted."
domainagent is a sysadmin on both Server A and B.
Trustworthy is set to ON in both the Master Server Database it's executing from and the remote databases on both A and B.
All 3 databases have the same owner (let's call it domainowner).
I am sorry for posting this question here. The only reason I am doing so is because Remus answered a question similar to this late last year, but I couldn't get access to the whole thread.
In SQL 2005, from a stored procedure in a local database I am attempting to execute a remote stored procedure in another database on another server. I am getting the error referred to in the Subject when the local stored procedure tries to execute the remote stored procedure. A couple of comments:
a.. The remote database is set up as a linked server in the local database. As part of the linked server definition I selected the 'be made using this security context', and provided a local user name and password. b.. The remote database is set to Trustworthy. c.. I have tried every combination of WITH Execute As on the remote stored procedure but nothing works. d.. I can query against the remote database successfully within Management Studio. I can even execute the remote stored procedure successfully from within M.S., but not from within my local stored procedure when it is run.
I have a stored procedure servicing a queue (sql 2005). The stored procedure updates some data in a different server and database. If the queue contains messages and I execute manually the stored procedure, I don't have any problem at all. However, if I set the queue to use the same stored procedure, it gives me the following error:
Error 15274: Access to the remote server is denied because the current security context is not trusted.
I am experiencing a head-scratcher of a problem when trying to use a Linked Server connection to query a remote SQL Server database from our SAP R/3 system. We have had this working just fine for some time, but after migrating to new hardware and upgrading OS, DBMS, and R/3, now we are running into problems.
The target database is a named instance on SQL Server 2000 SP3, Windows 2000 Server. The original source R/3 system was also on SQL Server 2000 (SP4), Windows 2000 Server. I had been using a Linked Server defined via SQL Enterprise Manager (actually defined when the source was on SQL Server 7), which called an alias defined with the Client Network Utility that pointed to the remote named instance. This alias and Linked Server worked great for several years.
Now we have migrated our R/3 system onto new hardware, running Windows Server 2003 SP1 and SQL Server 2005 SP1. I redefined the Linked Server on the new SQL 2005 installation, this time avoiding the alias and referencing the remote named instance directly, and it tests out just fine using queries from SQL Management Studio. It also tests fine with OSQL called from the R/3 server console, both when logged on as the application service account with a trusted connection, and with a SQL login as the schema owner. From outside of the application, I cannot make it fail. It works perfectly.
That all changes when I try to use the Linked Server within an SAP custom program (ABAP), however. The program crashes with a database interface error. The database error code is 15274, and the error text is "Access to the remote server is denied because the current security context is not trusted."
I have set the "trustworthy" property on the R/3 database, I have ensured the service account is a member of the sysadmin SQL role, I've even made it a member of the local Administrators group on both source and target servers, and I've done the same with the SQL Server service account (it uses a domain account). I have configured the Distributed Transaction Coordinator on the source (Win2003) system per Microsoft KB 839279 (this fixed problems with remote queries coming the other way from the SQL2000 system), and I've upgraded the system stored procedures on the target (SQL2000) system according to MS KB 906954. I also tried making the schema user a member of the sysadmin role, but that was disastrous, resulting in an instant R/3 crash (don't try this in production!), so I set it back the way it was (default).
What's really strange is no matter how I try this from outside the R/3 system, it works perfectly, but from within R/3 it does not. A search of SAP Notes, SDN forums, SAPFANS, Microsoft's KnowledgeBase, and MSDN Forums has not yielded quite the same problem (although that did lead me to learning about the "trustworthy" database property).
Any insight someone could offer on this thorny problem would be most appreciated.
Hi guys. I created a database "MyDatabase" using an AD Account "user01" which is a member of a domain group "GroupA". I have created a login in my SQL Server 2005 for this AD group. I have also added the said login as a user of my database. I created other AD users and put them in the same group. When I try to access the database using the other users, I get this message
The server principal "MyDomainuser02" is not able to access the database "MyDatabase" under the current security context.
This KB tells me that my situation is triggered by the first case in which the owner of the database is windows authenticated. I have already set the database to be TRUSTWORTHY. I haven't tried CERTIFICATES though. I believe I haven't done anything complex to warrant this solution.
I'm really lost with the myriads of principals and securables that SQL2005 has. All I want is just to execute a certain set of stored procedures. I can't do this because I can't even execute "USE MyDatabase". What are the permissions I need to give to "GroupA" ?
SQL2005 on winserver 2003. I have a view in Xdb that accesses tables in 2 different databases (Xdb and Ydb) on the same server. I have mixed mode security. I have a SQL user (XYuser) that has read access to all tables and views on both databases, yet when I try to access the view using a C# windows application I get the following error:
The server principal "XYuser" is not able to access the database "Ydb" under the current security context
This same scenario works under SQL 2000. I looked through the postings and tried to set TRUSTWORTHY ON on both databases but that didn't help. I can access any other views or tables on the SQL 2005 server, just not the one that joins the tables cross databases. Any help is much appreciated... john
I have a login that is mapped to a Windows sysadmin account. I used it to login to Sql Server 2005. I then created a database called Freedom. I then added a Windows login and user called FreedomAdmin, with Freedom set as the default database. When I login in to Windows using FreedomAdmin and then try to login in to Sql Server 2005, I get the following error:
The server principal "FREEDOM1FreedomAdmin" is unable to access the database "master" under the current security context.
If the default database for FreedomAdmin is Freedom (and it is - I checked from my sysadmin login account), why can't I login. Must I give FreedomAdmin permissions to master?
From my desktop in Management Studio (MS) I can connect to server A and run a query like, select top 1 * from serverB.mydatabase.dbo.mytable, and all seems to be working. If I leave and come back after a few minutes it no longer works and I get this error: Msg 18452, Level 14, State 1, Line 1
Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.
If I remote connect to server B and run the query it works and when I try it from my desktop MS it starts working again. Any ideas on why this is happening?
hi at all, i know that in here there was a lot of thread over this argument, but none can helps me. I'm newbie on sqlserver. I'm first installed an instance of SQL Server 2000 with enterprise manager. As previous topics i cannot log into server because 'sa' user is not associated with a trusted connection. In installation time i selelected "windows only" authentication (because in mixed mode at end of installation i caught an error and installation was canceled). Now i **must** to connect with "sa" user, because i must to connect on sql server via jdbc driver from a java application. So i really cannot use windows authentication, but i must use sql authentication. Someone, ***please*** (i'm really deprived of hope, i spent 1 entire day to install correctly server and client components!!!!), can guide me to configure my installed sql server instance to accept connections with sql authentication? My sql server version is 8.00.194.
Does anyone know of a component or other mini application that can be run on the IIS server and allow IIS to access SQL Server 7 databases using Trusted Security.
Our security unit has required us to run SQL Server with Trusted Security so changing to Mixed mode is not an option. We are also not allowed to use Basic Authentication for Active Server Pages with IIS. IIS and SQL server are also on different machines.
We are looking into the possibility of trying to create a component that would run on the IIS machine to allow us to use Trusted Security to the SQL Server (in effect try to make it work the same way that the Cold Fusion product does).
I have two win2003 servers. One is IIS and the another is SQL server. Ican use MyConnection=newSqlConnection("server=SQLServerName;database=myDBName;UID=sa;PWD= mypwd")to access my data. But I can not use MyConnection=newSqlConnection("server=SQLServerName;database=myDBName;IntegratedSecurity=SSPI") to access it. If I put both IIS and SQL Server in onemachine, I can do anything. How can I do something to allow trustedauthority work ?Thanks
I am using XP_CMDSHELL to run 2 Windows commands (from a SQL 2005 SP2 server) that access files on a remote server (called webserver). The two commands are:
1. cscript.exe \webserverwwwrootEur_SaveProductImages.vbs 2. dir \webserverwwwroot Up until very recently this worked fine. Now I am getting Access Is Denied errors:
For #1: Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. CScript Error: Loading script "\webserverwwwrootEur_SaveProductImages.vbs" failed (Access is denied. ).
For #2: Access is denied.
This happens if the above commands are run through a job, or directly with Query Analyzer as SA.
I understand that XP_CMDSHELL commands are run in the security context of the SQL Server startup account. The SQL Server startup account is called SQLServer and this account exists on both webserver and the database server. On both servers the username & password are identical and the user is in the local Administrators group. The two servers are in a workgroup.
Things I have tried (with no effect):
1. Restarted the servers 2. Deleted and recreated the SQLServer login on both servers 3. Changed the startup account for SQL Server through the SQL Server Configuration Manager to another account and back to SQLServer.
The most revealing tests are these:
1. If I log into the database server myself using the SQLServer account I can run the above commands in a Command Prompt with no problem
2. I installed SQL 2005 Express SP2 on webserver using the same startup account (SQLServer). If I run the same XP_CMDSHELL commands as above but accessing files on the database server, the commands work! So, an XP_CMDSHELL command run under SQL Express using the local SQLServer account to access a remote server works, but an XP_CMDSHELL command run under SQL Server using a local SQLServer account (that is supposedly identical to the same named account on the other server) does not work !!?!?!?
It is almost as if XP_CMDSHELL commands run under SQL Server are NOT using the SQLServer startup account, but using some other weaker account. How can I tell if this is true?
How can I get this back working (as it was a week ago). The only thing I can think that happened on the servers to cause this is the installation of Windows Updates.
I am trying to use a linked server and it works as long as I do not specify the sp_addlinkedserver @provstr parameter. If I specify that parameter I always get a 7416 "Access to the remote server is denied because no login-mapping exists" error. I have tried adding the logins various ways but it's very specific to the @provstr parameter, and it doesn't even matter what I put in that parameter. As soon as I put something in there whether it is valid or invalid, I get the error.
Anyone else seen this? There is an amazing lack of any discussion about the error when I search for it.
It doesn't even make any difference what I put in the @provstr parameter - the sp_addlinkedserver statement always executes without an error, but running a query that uses the linked server generates the error.
I am getting the following message when trying to connect to a database (from an external application) that I have recently restored using my profile (Windows Authentication):
Connection failed: SQLState: '01S00' SQL Server Error: 0 [Microsoft][SQL Server Native Client 11.0]Invalid connection string attribute Connection failed: SQLState: '08004' SQL Server Error: 4060 Server rejected the connection; Access to selected database has been denied Connection failed: SQLState: '28000' SQL Server Error: 18456 [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user 'xxxxaaaa'.
My profile (replaced with xxxxaaaa) has full access to the server and I can connect to every other database with no issues. I get exactly the same error if I try and connect using the SQL Authentication "sa" profile as well.
I created a maintenance plan to do the backup on my machine and created a job using CmdExec command: copy e:\*.bak \remoteackup but the copy job fail each time.
I know that command works fine when i run it from a batch file but does not seem to work from the job in sql server. I try to map the remote machine to a drive and used the drive in the copy statementcopy e:ackup*.bak q:ackup but it still does not work. Is there something I need to do inside sql server?
Event 17204, FCB::Open failed: Could not open file F:MSSQLDatafilename.mdf for file number 1. Â OS error: 5(Access is denied.).When I look at the file permissions of filename.mdf, there is no MSSQLSERVER group permissions listed nor can I add it. I have tried to add MSSQLSERVER and NT SERVICEMS SQL $MSSQLSERVER but neither exist. There is also a ReportServer.mdf in the same folder with MSSQLSERVER permissions!Did I somehow delete this group? What can I do to restore this permission?
We have 2 SQL2005 servers currently. 1 is a dev box, the other production. To grant remote access to SSIS, I added my developers to the local Distributed COM Users group and also gave them remote Access and remote Activation on the MsDtsServer component.
This worked just fine. Recently we applied SP1 and the follow-on hotfixes to all SQL components. I followed the install order prescribed in the Q article and applied all component fixes. My developers are now unable to access SSIS remotely unless I add them to the local administrator's group. I don't see anywhere that a log gets generated to help me track down what's going on. Nothing shows up in my Windows security log, despite enabling audit logging on: Accout Logon Events, Logon Event, Object Access, and Privilege Use.
Is this a know issue in SP1 or the hotfixes? I'm hesitant to apply the patches to my production box until I can resolve this issue.
What OS permissions do I need to give a domain user to effectively connect to a remote instance of Integration Services?
I keep getting the following message:
Cannot connect to SQLDEV01 Failed to retreive data for this request. Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) (Microsoft.SqlServer.ManagedDTS)
I have already performed the Windows 2003 steps outlined in the "Eliminating the Access is Denied" error located at http://msdn2.microsoft.com/en-us/library/aa337083.aspx
I have no problem if the user is a local Administrator (go figure).
I am finishing a port of a project that was done with RS2000/AS2000/DTS2000. The cube process is triggered remotely by a Korn Shell script from Services for Unix that runs a DTS package:
I have finished porting the AS and RS parts to their 2005 equivalents and now I am trying to get the cube processing converted. I have built a SSIS package that processes the cube and I have deployed it to the SQL Server in MSDB. When I am logged on to the SQL Server box directly, I can execute the package via the Management Studio and from the command line via:
When I try to register the SQL Server in Integration Services from my client PC Management Studio it fails with "Access Denied". When I try to run the dtexec from my client PC it fails with "Access Denied".
I have walked through Kirk Haselden's instructions at:
(adding myself to Distributed COM Users, noting the correct DCom Config settings for MsDtsServer and restarting the Integration Services service) and the problem is still not resolved. I have posted to the DTS group on Technet and now I am posting here. This can not be run scheduled by SQL Agent as it needs to be triggered by other load/postload activities. Are there any other fixes for this problem that I can try?
Thanks,
Keehan
By the way, being able to have all the parts of this project in one dev environment is great. The previous application was developed in 3 separate locations which was pretty clunky.
I'm new to SSIS and I'm having problems getting a remote connection to the SSIS service using Management Studio on my workstation. If I terminal Service onto the Server I have no problems connecting to SSIS, but if I try to connect remotely I get the "Access is denied" error message. I have completed the following steps:
To configure rights for remote users on Windows Server 2003 or Windows XP 1. If the user is not a member of the local Administrators group, add the user to the Distributed COM Users group. You can do this in the Computer Management MMC snap-in accessed from the Administrative Tools menu. 2. Open Control Panel, double-click Administrative Tools, and then double-click Component Services to start the Component Services MMC snap-in. 3. Expand the Component Services node in the left pane of the console. Expand the Computers node, expand My Computer, and then click the DCOM Config node. 4. Select the DCOM Config node, and then select MsDtsServer in the list of applications that can be configured. 5. Right-click on MsDtsServer and select Properties. 6. In the MsDtsServer Properties dialog box, select the Security tab. 7. Under Launch and Activation Permissions, select Customize, then click Edit to open the Launch Permission dialog box. 8. In the Launch Permission dialog box, add or delete users, and assign the appropriate permissions to the appropriate users and groups. The available permissions are Local Launch, Remote Launch, Local Activation, and Remote Activation. The Launch rights grant or deny permission to start and stop the service; the Activation rights grant or deny permission to connect to the service. 9. Click OK to close the dialog box. Close the MMC snap-in. 10. Restart the Integration Services service.
But I still get the Access is denied error from my workstation??
I have Power User rights on the server and I'm a sysadmin in the database instance. The SSIS packages I am trying to access are stored in the database. If I add myself to the local administrators group on the server I CAN get remote access, but this is not an acceptable solution in our production environment.
I'm creating an app that will connect to a central sql server 2005 (hosted on a Win2003 server with Windows Firewall on). I added sqlservr.exe and sqlbrowser.exe to the firewall exceptions to allow for remote connections. Now, an admin I know is telling me that this is not secure and we must configure those 2 exe's to only be accessed by certain IP addresses. I want to make sure the database is very secure, but this sounds like overkill. ??
Questions: Is this necessary (to limit access to these 2 exe's to certain IP addresses)? How would I be able to distribute my application to different users if this is so? How can I make sure that the SQL Server won't get "attacked" or "hacked"?
SQL Server in on a ‘member’ server in my company domain (We took the ‘stand-alone’ option when installing NT on this server).
I have set up an NT domain account for SQL ServerAgent ‘Service startup account’ which is a different account than the NT domain account listed in the SQL Server Properties, Security tab, ‘Startup service account’.
I log on to this server with the login in the latter.
Replication is working OK, but my application log keeps filling up with the message “SQLServerAgent security context does not have server autorestart privileges”.
I am writing a trigger to audit changes to certain columns. In the trigger I would like to record to the "Audit" table as much information about the current execution context as possible (current user, login, nt user, inputbuffer, etc.). I couldn`t find the way to find out what is the currently executed* stored procedure. @@PROCID returns object id for the trigger itself. Any help would be highly appreciated as this is an urgent production environment issue.
I'm using a legacy application built using VB5 and SQL Server 7. After recompiling it, and putting the database in SQL Server 2012. I want to access the current login user using the SQL function SUSER_SNAME().
This is the code.
Set rdoRes = goDatabase.Connection.OpenResultset("select suser_sname()")
But I'm unable to get the current user login in the application. If I write any other SQL statement instead of this, then it runs. But only this statement is not running. Is there any security reasons for this?
Any way to find out who's causing "Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection." error in SQL Server error logs?
I have a piece of Java code that needs to connect to SQL 2000 (SP4) using Windows Authentication. It's running on Windows Server 2003 SP1.
I tried JDBC v1.1 and followed the code from the following blog:
http://blogs.msdn.com/angelsb/default.aspx?p=1
But still get this error as shown below. Any help appreciated.
I am using JDK1.4.2, "sqljdbc_auth.dll" is located under "E:SQL2005JDBCDrvsqljdbc_1.1enuauthx86", also made a copy under "E:JavaTest" and "C:WindowsSystem32" but still won't work.
E:JavaTest>java -classpath ".;E:JavaTestsqljdbc.jar" -Djava.library.path=E:S QL2005JDBCDrvsqljdbc_1.1enuauthx86 TestW2 com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection. at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError (Unknown Source) at com.microsoft.sqlserver.jdbc.IOBuffer.processPackets(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerConnection.processLogon(Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerConnection.logon(Unknown Source ) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(Unknow n Source) at com.microsoft.sqlserver.jdbc.SQLServerConnection.loginWithoutFailover (Unknown Source) at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(Unknown Sour ce) at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(Unknown Source) at java.sql.DriverManager.getConnection(Unknown Source) at TestW2.main(TestW2.java:7) ===========================================================
The code is simple (TestW2.java):
import java.sql.*;
public class TestW2 { public static void main(String[] args) { try { java.lang.Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver"); Connection conn = java.sql.DriverManager.getConnection("jdbc:sqlserver://VMW2k3ENT003.TESTCBFPOC.COM.AU;integratedSecurity=true"); System.out.println("Connected!"); conn.close();
Hi,I've got some strange problem with my project. It was working, but then I made some minor changes (like adding menu) which have nothing to do with the code and I started to get that error: Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0103: The name 'SqlDataSource1' does not exist in the current context Source Error:
Line 22: Guid _userKey = (Guid)_membershipUser.ProviderUserKey; //This gets the userId for the currently logged in userLine 23: //insert instruction for table messageLine 24: SqlDataSource1.InsertCommand = "insert into [message](useridsender,userIdreceiver,message,Sendername, ReceiverName) values('" + _userKey + "'" + "," + "'" + DropDownList1.SelectedValue + "'" + "," + "'" + TextBox1.Text + "'" + "," + "'" + _membershipUser + "'" + "," + "'" + DropDownList1.SelectedItem + "');";Line 25: SqlDataSource1.Insert();Line 26: What does it mean? The names are correct, but the part with code (ie. something.aspx.cs) acts as if it has no information about the aspx file itself. How can I repair it?Regards,N.
