Related
I am working on an ios project that has a Sybase (ultralite) database that is synchronized with a Sybase Sql Anywhere 12 database using mobilink.
Everything was properly, until i decided today to add some fields to the main database so that they synchronize to the main database.
I have updated the schema of the consolidated database from the main engine, then i have updated the schema of the remote database from the consolidated engine, and then i mapped the added fields together, and I deployed a new ultralite database.
Please note that it's not the first time I do a similar task, i always add fields, and sync databases..
after the update, when i synchronize using the blank ultralite database, mobilink will fail giving only this error: Synchronization Failed: -1305 (MOBILINK_COMMUNICATIONS_ERROR) %1:201 %2: %3:0
I have researched Error Number 201 in sybase and it points to: SQLE_NOT_PUBLIC_ID
and in the sybase documentation the error's probably cause is:
"The option specified in the SET OPTION statement is PUBLIC only. You cannot define this option for any other user."
I have tried to redeploy, I have tried to move the engine to a windows pc, all give the same error.. and i have no clue where this SET OPTION statement came from and how can i solve it..
Any hints are appreciated!
The problem was just caused by small network timeout value while setting up mobilink parameters.
info.stream_parms = (char*) #"host=192.168.0.100;port=3309;timeout=1"
i just changed the value from timeout=1 to timeout=300 and it worked!
I'm developing an asp.net mvc application at my office. I wanted to work at home as well, so, I pushed my project on github, when I came my home back, I pulled it from github to my projects folder, now I tried to access its SQL Server database in server explorer using windows authentication, on pressing ok, it showed me the following error :
Cannot open database "HrAndPayrollSystem.Models.HrAndPayroll" requested by the login. The login failed.
Login failed for user 'user'.
and here is my connection string :
<connectionStrings><add name="HrAndPayroll" connectionString="Data Source=(LocalDb)\MSSQLLocalDB;Initial Catalog=HrAndPayrollSystem.Models.HrAndPayroll;Integrated Security=False" providerName="System.Data.SqlClient" />
What could be the reason, how should I resolve it? Thanks in Advance :)
So, I somehow managed to get through this.
In other words, this error says that you need to access your database at least for a single time, means you need to perform some transactions with the database, inserting something or retrieving something, at this point you accessed the database for the first time on the different machine. Since, I had to access database at the point when my application starts, so, crashing start crashes my whole application, so I created another controller that does not contain any authorize attribute, just to leave it open in order to access the database, created a single field, accessed the database, now go and check your database in server explorer, you are about to access it for the first time in the database, and now also, it will never crash anywhere.
So, the point is that you need to access your database at least for a first time..
I followed a tutorial on the internet to create my own database. I succesfully built a program upon it. Then I created an access .mdb file(another database) and then I just changed the database which the program connected to, to the one which I created.
I just made that one change. But then it started showing me error whenever I tried to update using
da.update(ds,"Phone Book")
where da is data adapter and ds is data set.
The error was: " syntax error in INSERT INTO statement"
I have just changed the DB that the program is connecting to. I did not change the code one bit.
EDIT: I forgot to mention, I searched for this on google, and one thing which I read was, that access database might be only read only or something. But I unchecked the read only box, so I don't know whether it still might be the problem. Although, I don't think there is a problem with the code
EDIT: I just discovered now, that even if I change the table which is being referred to, it throws up the same error.
It sounds like the first database probably used something like Sql Server Express. That's a completely different kind of database then Access, with a different providers, different dialect of SQL, connection string, etc. Why would you think you can change all that without breaking some of your code?
Have just deployed my Project on to my reporting Server.
I have multiple datasets which are referencing views which exist on the db on that server.
When I try to go into any report part I am getting this message:
An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'dataset1'. (rsErrorExecutingCommand)
For more information about this error navigate to the report server on the local server machine, or enable remote errors
Can anyone help?
I enabled remote errors to pinpoint the problem.
I identified that a column in a particular dataset (one of my views) was throwing an error.
So using a tool "SQL Delta", I compared the development version of the database with the live version on the reporting server. I noticed that one of the views had an extra column on the development server, that was not on the live version of the db.
SQL Delta generated the script I needed to run to update the view on my live db.
I ran this script, re-ran the report, everything worked.
I encountered a similar error message. I was able to fix it without enabling remote errors.
In Report Builder 3.0, when I used the Run button to run the report, an error alert appeared, saying
An error has occurred during report processing. (rsProcessingAborted)
[OK] [Details...]
Pressing the details button gave me a text box where I saw this text:
For more information about this error navigate to the report server
on the local server machine, or enable remote errors
----------------------------
Query execution failed for dataset 'DataSet1'. (rsErrorExecutingCommand)
I was confused and frustrated, because my report did not have a dataset named 'DataSet1'. I even opened the .rdl file in a text editor to be sure. After a while, I noticed that there was more text in the text box below what I could read. The full error message was:
For more information about this error navigate to the report server
on the local server machine, or enable remote errors
----------------------------
Query execution failed for dataset 'DataSet1'. (rsErrorExecutingCommand)
----------------------------
The execution failed for the shared data set 'CustomerDetailsDataSet'.
(rsDataSetExecutionError)
----------------------------
An error has occurred during report processing. (rsProcessingAborted)
I did have a shared dataset named 'CustomerDetailsDataSet'. I opened the query (which was a full SQL query entered in text mode) in SQL Server Management Studio, and ran it there. I got error messages which clearly pointed to a certain table, where a column I had been using had been renamed and changed.
From that point, it was straightforward to modify my query so that it worked with the new column, then paste that modification into the shared dataset 'CustomerDetailsDataSet', and then nudge the report in Report Builder to recognise the change to the shared dataset.
After this fix, my reports no longer triggered this error.
Like many others here, I had the same error. In my case it was because the execute permission was denied on a stored procedure it used. It was resolved when the user associated with the data source was given that permission.
I experienced the same issue, it was related to security not being granted to part of the tables. review your user has access to the databases/ tables/views/functions etc used by the report.
The solution for me came from GShenanigan:
You'll need to check out your log files on the SSRS server for more detail. They'll be somewhere like: "C:\Program Files (x86)\Microsoft SQL Server\MSRS10_50.DEV\Reporting Services\LogFiles\"
I was able to find a permissions problem on a database table referenced by the view that was not the same one as the where the view was. I had been focused on permissions on the view's database so this helped pinpoint where the error was.
I just dealt with this same issue. Make sure your query lists the full source name, using no shortcuts. Visual Studio can recognize the shortcuts, but your reporting services application may not be able to recognize which tables your data should be coming from. Hope that helps.
I had the similar issue showing the error
For more information about this error navigate to the report server on
the local server machine, or enable remote errors Query execution
failed for dataset 'PrintInvoice'.
Solution:
1) The error may be with the dataset in some cases, you can always check if the dataset is populating the exact data you are expecting by going to the dataset properties and choosing 'Query Designer' and try 'Run', If you can successfully able to pull the fields you are expecting, then you can be sure that there isn't any problem with the dataset, which takes us to next solution.
2) Even though the error message says "Query Failed Execution for the dataset", another probable chances are with the datasource connection, make sure you have connected to the correct datasource that has the tables you need and you have permissions to access that datasource.
In my situation, I created a new SSRS report and new stored procedure for the dataset. I forgot to add the stored procedure to the database role that had permission to execute it. Once I added the permissions to SQL database role with EXECUTE, all was fine!
The error message encountered by the user was "An error occurred during client rendering. An error has occurred during report processing (rsProcessingAborted). Query execution failed for dataset "DataSet1'. (rsErrorExecutingCommand) For more information..."
Very grateful I found this great post. As for my case, the user executing the stored procedure did not have EXECUTE permissions. The solution was to grant EXECUTE permissions for the user within the stored procedure by adding below code to the end of the stored procedure.
GRANT EXECUTE ON dbo.StoredProcNameHere TO UsernameRunningreports
GO
I also had a very similar issue with a very similar error message. My issue was that the database could not be connected to. In our case, we have mirrored databases and the connection string did not specify the Failover Partner. So when the database couldn't connect, it never went to the mirror and was throwing this error. Once I specified the Failover Partner in the connection string for my datasource, it resolved the issue.
BIGHAP: A SIMPLE WORK AROUND FOR THIS ISSUE.
I ran into the same problem when working with SharePoint lists as the DataSource, and read the blogs above which were very helpful. I had made changes in both the DataSource and Data object names and query fields in Visual Studio and the query worked in visual Studio. I was able to deploy the report to SharePoint but when I tried to open it I received the same error.
I guessed that the issue was that I needed to redeploy both the DataSource and the DataSet to SharePoint so that that changes in the rendering tools were all synced.
I redeployed the DataSource, DataSet and the Report to sharePoint and it worked.
As one of the blogs stated, although visual studio allowed the changes I made in the dataset and datasource, if you have not set visual studio to automatically redeploy datasource and dataset when you deploy the report(which can be dangerous, because this can affect other reports which share these objects) this error can occur.
So, of course the fix is that in this case you have to redeploy datasource, dataset and Report to resolve the issue.
I was also facing the same issue - I checked below things to fix this issue,
If you have recently changed pointing database-name in data-source
then first check that all the store procedures for that report exist
on changed database.
If there are multiple sub reports on main report then make sure each
report individually running perfectly.
Also check security panel - user must have access to the databases/
tables/views/functions for that report.
Sometimes, we also need to check dataset1 - store procedure. As if you are trying to show the report with user1 and if this user doesn't have the access(rights) of provided (dataset1 database) database then it will throw the same error as above so must check the user have access of dbreader in SQL Server.
Also, if that store procedure contains some other database (Database2) like
Select * from XYZ inner join Database2..Table1 on ... where...
Then user must have the access of this database too.
Note: you can check log files on this path for more details,
C:\Program Files\Microsoft SQL Server\MSRS11.SQLEXPRESS\Reporting Services
I got same error but this worked and solved my problem
If report is connected to Analysis server then give required permission to the user (who is accessing reporting server to view the the reports) in your model of analysis server.
To do this add user in roles of model or cube and deploy the model to your analysis server.
Using SSRS, Report Builder 3.0, MSSQL 2008 and query to an Oracle 11G database,
I found that the oracle stored procedure ran well, produced consistent results with no errors. When I tried bringing the data into SSRS, I got the error as listed in OP's query. I found that the data loaded and displayed only if I removed the parameters (not a good idea).
On Further examination, I found that under dataset properties>parameters I had set the start date to parameterName P_Start and parameter Value to #P_Start.
Adding the Parameter value as [#P_Start] cleared the problem, and the data loads well, with parameters in place.
This problem was caused by an orphaned SQL Login. I ran my favorite sp_fixusers script and the error was resolved. The suggestion above to look at the logs was a good one...and it led me to my answer.
This might be the permission issue for your view or store procedure
In addition to the above answers, it could be due to a missing SQL stored-procedure or SQL function. For example, this could be due to the function not migrating from a non-prod region to the production (prod) region.
Removing all comments from the Select Query fixed this for me. My dataset was working in the Preview but when I went to Design/Query Designer and and tried the query there I was getting ORA-01006;bind variable does not exist. After removing all comments from the select it worked.
We have a classic ASP application that simply works and we have been loathe to modify the code lest we invoke the wrath of some long-dead Greek gods.
We recently had the requirement to add a feature to an application. The feature implementation is really just a database operation requires minimal change to the UI.
I changed the UI and made the minor modification to submit a new data value to the sproc call (sproc1).
In sproc1 that is called directly from ASP, we added a new call to another sproc that happens to be located on another server, sproc2.
Somehow, this does not work via our ASP app, but works in SQL Management Studio.
Here's the technical details:
SQL 2005 on both database servers.
Sql Login is authenticating from the ASP application to SQL 2005 Server 1.
Linked server from Server 1 to Server 2 is working.
When executing sproc1 from SQL Management Studio - works fine. Even when credentialed as the same user our code uses (the application sql login).
sproc2 works when called independently of sproc1 from SQL Management Studio.
VBScript (ASP) captures an error which is emitted in the XML back to the client. Error number is 0, error description is blank. Both from the ADODB.Connection object and from whatever Err.Number/Err.Description yields in VBScript from the ASP side.
So without any errors, nor any reproducibility (i.e. through SQL Mgmt Studio) - does anyone know the issue?
Our current plan is to break down and dig into the code on the ASP side and make a completely separate call to Server 2.sproc2 directly from ASP rather than trying to piggy-back through sproc1.
Have you got set nocount on set in both stored procedures? I had a similar issue once and whilst I can't remember exactly how I solved it at the moment, I know that had something to do with it!
You could be suffering from the double-hop problem
The double-hop issue is when the ASP/X page tries to use resources that are located on a server that is different from the IIS server.
Windows NT Challenge/Response does not support double-hop impersonations (in that once passed to the IIS server, the same credentials cannot be passed to a back-end server for authentication).
You should verify the attempted second connection using SQL Profiler.
Note that with your manual testing you are not authenticating via IIS. It's only when you initiate the sql via the ASP/X page that this problem manifests.
More resources:
http://support.microsoft.com/kb/910449
http://support.microsoft.com/kb/891031
http://support.microsoft.com/kb/810572
I had a similar problem and I solved it by setting nocount on and removing print commands.
My first reaction is that this might not be an issue of calling cross-server, but one of calling a second proc from a first, and that this might be what's acting differently in the two different environments.
My first question is this: what happens if you remove the cross-server aspect from the equation? If you could set up a test system where your first proc calls your second proc, but the second proc is on the same server and/or in the same database, do you still get the same problem?
Along these same lines: In my experience, when the application and SSMS have gotten different results like that, it has often been an issue of the stored procedures' settings. It could be, as Luke says, NOCOUNT. I've had this sort of thing happen from extraneous PRINT statements in the code, although I seem to remember the PRINTed value becoming part of the error description (very counterintuitively).
If anything is returned in the Messages window when you run this in SSMS, find out where it is coming from and make it stop. I would have to look up the technical terms, but my recollection is that different querying environments have different sensitivities to "errors", and that a default connection via SSSM will not throw an error at certain times when an ADO connection from a scripting language will.
One final thought: in case it is an environment thing, try different settings on your ASP page's connection string. E.g., if you have an OLEDB connection, try ODBC. Try the native and non-native SQL Server drivers. Check out what connection string options your provider supports, and try any of them that seem like they might be worth trying.
Example code might help :) Are you trying to return two tables from the stored procedure; I don't think ADO 2.6 can handle multiple tables being returned.
I did consider that (double-hop), but what is the difference between a sproc-in-a-sproc call like I am referring to vs. a typical cross-server join via INNER JOIN? Both would be executed on Server1, using the Linked Server credentials, and authenticating to Server 2.
Can anyone confirm that calling a sproc cross-server is different than doing a join on data tables? And why?
If the Linked Server config is a sql account - is that considered a double-hop (since what you refer to is NTLM double-hops?)
In terms of whether multiple resultsets are coming back - no. Both Server1.Sproc1 and Server2.Sproc2 would be "ExecuteNonQuery()" in the .net world and return nothing (no resultsets and no return values).
Try to check the permissions to the database for the user specified in the connection string.
Use the same user name in the connection string to log in to the database while using sql mgmt studio.
create some temporary table to write the intermediate values and exceptions since it can be a effective way of debugging your application.
Can I just check: You made the addition of sproc2? Prior to that it was working fine for ages.
Could you not change where you call sproc2 from? Rather than calling it from inside sproc1, can you call it from the ASP? That way you control the authentication to SQL in the code, and don't have to rely on setting up any trusts or shared remote authentication on the servers.
How is your linked server set up? You generally have some options as to how it authenticates to the remote server, which include logging in as the currently logged in user or specifying a SQL login to always use. Have you tried setting it to always use a specific account? That should eliminate any possible permissions issues in calling the remote procedure...