I use SQL Server 2012 and I have some databases on it. The problem is I suddenly get an error saying,
object reference not set to an instance of an object
I get this error when:
Going to write a new query
Select previously entered data by right click the table name ->
Select top 1000 rows
What I can do without getting error message:
Log into my instance successfully using both Windows Authentication mode and SQL Authentication mode.
Edit the table data by right click the table name -> Edit top 200 rows
Create a new database
I'm using:
Microsoft SQL Server Management Studio: 11.0.3128.0
Microsoft .NET Framework: 4.0.30319.34014
Operating System: Windows 8.1
Here are some snapshots of the error.
Please give me a solution to fix this problem. Your help will be highly appreciated.
I fixed the problem by running SSMS as administrator.
I could solve the error.
Repair the SQL Server.
Go to Add/remove programs Microsoft SQL Server 2012(x64) -> Uninstall/Change -> Repair.
Select the instance that you want to repair here.
For me, after repairing the instance, the error was solved.
Thanks for all who spent their valuable time to reply my question.
I got the same error message. Problem was 0 bytes free on the C: drive.
Its may be late, but i get the same error in SQL SERVER 2016, i resolved it by assigning full access to the back up folder.
I faced the same error once in my project. This is purely due to SSMS(sql client) is corrupted. Just for cross check that server is fine and client is corrupted, try to connect to the sql-server in this machine from any other server if you have access and query the tables. If it returns data, just uninstall and reinstall the client(ssms) to solve the issue
Thanks
I got the same error for SQL 2016 and the only solution for me was to completely uninstall (in appwiz.cpl) all entries Visual Studio + SQL. Then I executed VisualStudioUninstaller and I reinstalled SQL and after Visual Studio.
I got the same message when I try to alter table to add new column . Issue is I haven't enclosed data types using '[' datatype ']' . Its Real data type. But It got fixed when I enclosed in using square braces.
My solution for this was to extract the csv file with the python library pandas rather than saving it with Excel. Further, I removed columns that I didn't need as a few columns caused formatting errors during the import.
For those who are unable to modify their SQL configuration due to administrative restrictions at work:
I was able to open a new query page by creating a SQL Server Scripts project and adding a new query through the solution explorer
I got the message after deleting a database. The database was gone, so I moved on.
Related
I've done this numerous times in the past when connecting Access queries to Excel, but now when I try and do it with a SQL Server query, I get an error message of
[Microsoft][ODBC SQL Sever Driver]Invalid parameter number
before I can even assign the parameter a value.
Once I got this error message I started to look around online for some answers, and I came across this article here. I followed these steps, which is essentially what I was doing anyway, and I still get the same error. The article is a few years old, so I'm not sure if things have changed since the release of Excel 2016 (my current version).
Is this something that cannot be done anymore without using VBA?
Just to summarize my steps, this is what I have done:
From Other Sources > From Microsoft Query
Select Database from MS Query Prompt > Click SQL button
Paste SQL > Click Return Data Button
Click Definition in Connection Properties window> Swap criteria code with ? in Command Text
Click OK
It looks as though I may have found the issue. When doing the initial connection through MS Query, you are asked to select the data source. Apparently there are two SQL Server options, one named SQL Server and another named SQL Server Native CLient 11.0. Originally I chose SQL Server, after trying numerous ways to fix this issue, I deleted the data source completely from MS Query, and started over, this time I chose SQL Server Native Client 11.0 and it worked exactly as it should. I'm not entirely sure what the difference between the two are, but it seems to have made the difference.
I had this issue as well and it turns out that because I had included square braces around the procedure I wanted to execute it seemed to think it was a parameter. e.g.
exec dbo.[myproc] #foo=?
just changing to...
exec dbo.myproc #foo=?
worked fine.
I think behind the scenes the params are being put in an array and square brackets in the sql is confusing it. Hope this helps. It may well be that sql native client 11 doesn't handle the params in the same way so you bypass this problem.
I am trying out this exercise - http://azure.microsoft.com/en-us/documentation/articles/sql-database-get-started/
Instead of connecting to SQL Server Management Studio 2014, I am using Query in Azure Management Portal. However, I am stuck in Step 7 at a very simple query - "Select * Person". I kept getting error message saying - Invalid object name 'Per'. What was done incorrectly?
I tried but I am unable to repro your issue. You could try open the saved query in a text editor and change the text there, then save and open the file again in the management portal. That may work.
Also, you could try using SSDT https://msdn.microsoft.com/en-us/data/hh297027 for a better development experience.
Please try
SELECT * FROM Person
I am using SQL Server 2008 R2. It is working fine. But recently, I have changed my hosting server and I came to know that they have installed SQL Server 2012 on Server.
Now, Issue is that after connecting with Server Database through SQL Server 2008 R2, When I click on any table name or Stored Procedure, I am getting error : Index was outside the bounds of the array. (Microsoft.SqlServer.smo)
So, is there any issue from my side or It is from Server Side ??? and How can I prevent this issue ?
Restarting the Management Studio worked for me.
Upgrade your SqlServer management studio from 2008 to 2012
Or
Download the service packs of SqlServer Management Studio and update probably resolve you solution
You can download the SQL Server Management studio 2012 from below link
Microsoft® SQL Server® 2012 Express http://www.microsoft.com/en-us/download/details.aspx?id=29062
For me this problem still exists with SSMS version 2016 (13.0.16100.1).
A decent workaround is to not use the 'Right click' -> 'Add table...' dialog, but simply drag the table you want to add from the Object Explorer, onto the Diagram surface. While dragging the mouse icon changes into an 'add' symbol and the table is added when you release the mouse.
Beats having to close SSMS every time.
Restarted worked!
I found the same error to add new table to my database diagram on sql server 2016, restarted sql server management studio, finally solved.
This is an issue if you are using 2008 management studio tools to connect to a SQL 2012 instance.
I experience this a lot if I am working on one server with SQL 2008, and trying to quickly query another server that is running SQL 2012.
I normally keep my personal workstation on the latest version of management studio (2012 in this case), and am able to administer all servers from there.
The Reason behind the error message is that SQL couldn't show new features in your old SQL server version.
Please upgrade your client SQL version to same as your server Sql version
Solution: Ignore the error
Just to show that the error does not do much in SSMS version 18.9.2, drag the table to be shown in the diagram from the Object Explorer tab and wait for it to finish loading before you start using it.
The suggested causes are now proven to be mostly impossible. I'm running SSMS V17.9.2 against SS 2014 and still have the problem. Memory problems have existed with this tool since at least 2006 when I started using SSMS.
Yes, MS 'wants' to get rid of diagramming but users won't let them. I have a feeling they will never fix any of these issues because they want users to be so fed up with the tool that enough of them quit using it and they can abandon it entirely.
Restarting is still a workaround if you can stand doing so numerous times per day.
you must use new version of Management Studio. And also you will got an error 29506. so you should run as Administrator for setup.
Look this site.
http://shareis.com/post/29506-management-studio-express
I had a similar experience with using SMO via C# with the stack trace:
[1896] System.IndexOutOfRangeException: Index was outside the bounds of the array.
[1896] at Microsoft.SqlServer.Management.Smo.BitStorage.SetBit(Int32 itemIndex, BitIndex bitIndex, Boolean value)
[1896] at Microsoft.SqlServer.Management.Smo.SqlSmoObject.AddObjectPropsFromDataReader(IDataReader reader, Boolean skipIfDirty, Int32 startColIdx, Int32 endColIdx)
[1896] at Microsoft.SqlServer.Management.Smo.SqlSmoObject.ImplInitialize(String[] fields, OrderBy[] orderby)
[1896] at Microsoft.SqlServer.Management.Smo.SqlSmoObject.Initialize(Boolean allProperties)
[1896] at Microsoft.SqlServer.Management.Smo.SqlSmoObject.OnPropertyMissing(String propname, Boolean useDefaultValue)
[1896] at Microsoft.SqlServer.Management.Smo.PropertyCollection.RetrieveProperty(Int32 index, Boolean useDefaultOnMissingValue)
[1896] at Microsoft.SqlServer.Management.Smo.PropertyCollection.GetValueWithNullReplacement(String propertyName, Boolean throwOnNullValue, Boolean useDefaultOnMissingValue)
[1896] at Microsoft.SqlServer.Management.Smo.Information.get_MasterDBPath()
It turned out my versions of the CLR/NCLI/SMO were 10.50.1600.1.
Upgrading them to 10.53.6000.34 fixed it - thus allowing the 2008R2 SMO to do many things with 2012 and 2014 servers.
Get them from the feature pack
https://www.microsoft.com/en-gb/download/details.aspx?id=44272
I found an issue with Diagram and Schema in SQL-Server 2016 that could be useful to the subject.
I was editing diagram (related to, and with lot of tables of, the "sales" schema) and added a new table, BUT forgot to declare it schema, so it was with the default "dbo". Then when I returned to, and opened up, the schema "sales" and tried to add an existent table... Bluf! THAT Triggered exactly the same error described in that thread.
I even tried the workaround (drag the table) but it didn't work. Suddenly I noticed that the schema was incorrect, I updated it, tried again, and Eureka! the problem was immediately away... Regards.
It's very old problem with cashed content. MS planning to remove diagrams from SSMS, so they don't care about this. Anyway, solution exists.
Just close Diagrams tab and open it again. Works with SSMS 18.2.
You have to use latest version with SSMS
You can check latest builds via this page
https://sqlserverbuilds.blogspot.com/
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.
I am using SSIS with VS2010 (shell) and databases going from SQL Server 2005 (32 bit)to SQL Server 2012 (64 bit). I am developing directly on the destination server (not optimal, but it works).
When I try to use the Transfer database task, it gives me an error message as follows:
"Error: The Execute method on the task returned error code 0x80131500 (An error occurred while transferring data. See the inner exception for details.). The Execute method must succeed, and indicate the result using an "out" parameter."
Here is the problem... how do I view an "inner exception"?? it is a GUI interface with no way to step through the code! I even tried setting up logging - it just logs the same useless error message.
Microsoft has no information for this error code in their reference docs (that I could find).
After googleing the error code, I saw others have this error code along with messages having to do with users, roles, and creating them.
I double checked that I have sysadmin rights on both servers, and
logins on both.
I tried the same Transfer Database task from each
server to itself (with changeing database name) and that worked
fine for both by themselves.
I tried both DatabaseOnline and DatabaseOffline options. (same error both ways)
I tried doing a "Transfer Logins" task before doing the transfer database task, that task worked, but not the Transfer databases task. Then it started throwing errors saying that the databases don't exist - which implies that I need to transfer logins AFTER I transfer databases.
Here are my settings:
What am I doing wrong? OR how can I get the "inner exception" message?
Also, follow my post to Microsoft's forums here:
http://social.technet.microsoft.com/Forums/en-US/sqlintegrationservices/thread/cda53c80-8da6-4ed1-898a-9f3ff8464ae2
This answer makes me sick to my stomach... I hope I save someone else this hassle. The problem was this:
First and foremost: the error message was not descriptive enough. The error should be handed to the interface.
Under "edit" on a "Transfer Database" task, the destination file paths are "auto-populated" with the file paths of the source database. They look right at first (and second, and third...) cursory glance. Upon further inspection the file paths were wrong. This makes sense if you are going from version to version - the folders are named with subtle differences according to version (MSSQL.1 vs. MSSQL11.<instanceName>).
In summary, the error was caused by the folder not existing because the path was set wrong. I imagine other low-level exceptions like this are also eaten by the interface with the same cryptic error message.
This is old but I bumped in the same cryptic message with SSMS 17.2. I tried and checked all the suggestions above to no avail.
In my case the issue was related to the TargetServerVersion property of the SSIS project in Visual studio 2017. By default this was set to SQL Server 2017, while my local server was SQL Server 2014 - once changed to the same version everything went smooth.
We ran into this where someone told us a valid date would always exist in the column in a MySQL database and we found out later that there were dates like '0000-00-00 00:00:00' and '0001-01-01 00:00:00'.
We handled it in the query that pulls in the data using a case statement to convert the bad date into a date SSIS can use :
CASE WHEN Product.PurchaseDate < '1900-01-01 00:00:00' THEN '1900-01-01 00:00:00' ELSE Product.PurchaseDate END AS PurchaseDate
Of course, you can set it to null also, your choice.
I have also had this same issue and it turned out to be an access issues. Try giving these access to the folder where the mdf and ldf files will be landing: NT Service\MSSQLSERVER, Owner Creator, System
"which implies that I need to transfer logins AFTER I transfer
databases."
not really, logins are on a server (instance) level so you can transfer logins and then the database. You would need to worry about users later, of course
a point here, I dont think SSIS would be prepared to transfer 2005 -> 2012. I mean, It wouldn't make sense to "skip" a version. You said you are using VS 2012, so it would be SSIS 2012. It think it can read only 2008 databases. The fact that you tested on the same server and it worked also makes this point stronger.