I've had this current issue before, and the steps that I've used to resolve it in the past aren't working. I'm working with a database in SSMS, as well as through C#/.NET. When I encounter a bug on the C# side after connecting to the database, the db becomes inaccessible until I close visual studio, and then in prior situations, taking the db offline then on again. I'm looking for more ideas/ help, since after doing those things, a simple query:
SELECT TradeDate, Symbol, Clse
FROM tblDailyPricingAndVol
gives me
Msg 208, Level 16, State 1, Line 1
Invalid object name 'tblDailyPricingAndVol'.
(whereas it is valid, and I type it right after expanding it in object explorer in ssms).
Update:
Running that query with db/ schema prefix as such:
SELECT Market.dbo.TradeDate
FROM Market.dbo.tblDailyPricingAndVol
Returns the error:
Msg 945, Level 14, State 2, Line 1
Database 'Market' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.
Running this:
select name, state_desc, user_access_desc, is_read_only from sys.databases
tells me that my db is online. I closed visual studio and restarted my machine last night, then took the db offline then on, and I don't see anything like "recovery pending" etc. today still. I'd like to get back up and running, and if anyone can shed some light on this process of connecting/ disconnecting SQL Server 2008 with Visual Studio 2010, it'd be much appreciated..
A. Make a copy of your Market.mdf file and store it somewhere safe.
B. Run the following commands in a query window:
USE [master];
GO
ALTER DATABASE Market SET SINGLE_USER WITH ROLLBACK IMMEDIATE; -- may fail
GO
DROP DATABASE Market; -- may fail depending on whether this db really exists
GO
CREATE DATABASE Market ON ( FILENAME =
'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA\Market.mdf'
) FOR ATTACH;
GO
If this fails due to some error with the log file (.ldf), then try moving the market.ldf file elsewhere, and running:
CREATE DATABASE Market ON ( FILENAME =
'C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA\Market.mdf'
) FOR ATTACH_REBUILD_LOG;
To prevent similar problems in the future:
Don't detach your database.
Don't connect to your MDF file using the AttachDbFileName and User Instance settings.
Don't set your database to OFFLINE.
Don't set your database to Auto-Close.
Related
I've installed the ODT for Visual Studio 2015 (I've also tried VS2013) in hopes of using the "Oracle Database Project" but experiencing some specific error messages that don't appear to be very common.
When I browse the database via the Server Explorer, there is an option for you to be able to right click on a Relational Table and click "Generate Create Script to Project...".
However, when clicking this option I get a very non-specific error message and cannot work out why;
"Create script was not generated to Project for some of the selected object(s). See the 'Oracle Database Output' output pane for more information."
When I look at the "Oracle Database Output" window I get the message;
"Script Generation failed - Internal Error."
For here-on-in, it's gets very frustrating to find out what's wrong and to debug this non-descriptive error message.
What's most interesting is that the script generation function works for other database objects such as views & procedures, it just fails to work for database tables.
Has anybody experienced this error before? I'm wondering if it's a driver issue of some sort! (I have the oracle 11g client installed, and just tried with a specific ODAC/ODT combination package which appears to also install the 12c client, connecting to an Oracle Elements 11g server)
Any help appreciated, Thanks.
I have this problem too.
I was able to Create the scripts earlier, but now I cannot.
I did some investigating and decided this is not a problem with the oracle database. It is something to do with the state of VS.
I restarted VS2015 and I could create scripts again.
I have a quarterly update package that I run from the backend of our system that uses an Excel (2007 format) document as a data source. The package stages the data from the Excel document to a table within the database, where it is processed and loaded in the production system.
Today, I received the Q2 update for April 2015, and attempted to run the new file into the staging system through Visual Studio as I have in the past. But for some reason today, VS / SSIS appears to be stuck "Validating Excel Source". I've let it sit for up to 10 minutes, before having to kill my Visual Studio instance through Task Manager.
The source document is small and relatively uncomplicated on 6 columns and less that 300 Kb in size, so I can't understand the validation issue all of a sudden. It appears to be the same excel version and format as my previous runs.
This package has been untouched for the better part of year, only having to change a series of parameters for each quarterly run.
I've deleted the connection managers and excel components from the package and recreated them but still appear to have the same issue. I've also recreated the source document.
I attempted tp disabled the DelayValidation and ValidateExternalMetaData properties, in hopes that it might give me a meaningful error dialogue, but have yet to get past the "Validating Excel Source" message.
Any input would be appreciated, Thank you.
I appear to have found a resolution to the issue.
It appears that a recent update to my installed Office suite altered the driver for Excel on my machine.
The following articles helped me resolve the issue, but as it turned out I needed to reinstall the Office 2007 System Driver: Data Connectivity Components...(linked in the 2nd article)
Once installed I was able to reopen my solution and view the Excel document.
Thank you for the assistance.
Using Excel 2012 file in Excel Connection Manager
How to fix errors: "the 'microsoft.ace.oledb.12.0' provider is not registered on the local machine"
Remove the excel file that the connection manager is looking for from the directory that it is pointing to. Once you do that the Validation of the Excel source should fail when it can not find the file it is looking for. This should allow you to get into the package and set Delay Validation = True in the properties.
The package validates the excel connection manager the same as it would any other OLE DB connection manager. It confirms connection and then runs your statement to validate the return of data. If you take away its source it should flame out quickly.
I have found that background processing on your machine can block this validation or processing of the request the same as a priority query might in SQL. If you machine is in a state with a number of priority tasks running this validation is put on the back burner and can and will take forever. In cases like this the connection used to the source being used to validate with either disconnect or timeout and it is not handled in the UI so it just hangs and locks up.
Using VS2010 code first and SQL Server 2008r2 with an MVC3 webapp, the SetInitializer creates a db as expected when missing or on model changes.
The db created has the filename format database.mdf and the **logfile database.ldf (can this default "name.ldf" format be changed to "name_log.ldf"?).
When opening the database with VS2010 server explorer (double-clicking the db in solution explorer), the VS2010 creates a new second logfile formatted database_log.ldf.
I can now browse the database in VS2010 server explorer, but can no longer debug, dropcreateonmodelchange or otherwise use the db.
When trying to debug error shown is:
{"One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct files. If this is an existing database, the file may be corrupted and should be restored from a backup.\r\nCannot open database \"database\" requested by the login. The login failed.\r\nLogin failed for user 'My-PC\Me'.\r\nLog file 'C:\Users\Me\project\App_Data\database.ldf' does not match the primary file. It may be from a different database or the log may have been rebuilt previously."}
...which is fair enough since the project is expecting the current log file to be "database.ldf".
The ASPNETDB.MDF and aspnetdb_log.ldf files/names are also created and don't have the default log file name issue, so the issue doesn't apply to ASPNETDB.
Is it possible to change the default log file name for the SetInitializer to create a "database_log.ldf" formatted log file name instead of the "database.ldf"? I've googled without success, and looked at all the settings and options I could find in VS2010. Is the format stored in a config file somewhere that can be hand edited?
To continue using the database in VS2010, I've ended up deleting the database.ldf log file, and renaming the new database_log.ldf file to the original database.ldf name.
It's not elegant or correct, but it works for development.
This doesn't address the incorrect behaviour of codefirst creating one version of the log file and server explorer creating a second differently named logfile at different stages of the development process within the same VS2010 environment.
I've got exactly the same problem using VS2010 Express and SServer 2012 Express. I'm trying to work through Julie Lerman's book Programming Entity Framework 2nd Edition.
Is there no better solution than this - renaming the logfiles? I've tried to rename the files, but Windows will tell me that the file is in use, even when I shutdown both VS and SSMS. A Process Explorer search for the DB tells me that the file is in use by SServer.
I've found that all I have to do is try to create a connection string using the DB Connection wizard, and the DB in SServer gets the "extra" logfile created, and I get the same message you are seeing.
Is this a bug in VS2010Ex? Are there patches available? How do we prevent VS2010 from corrupting the DB?
Here is the directory after creating the DB, but before trying anything from VS:
E:\Program Files (x86)\Microsoft SQL Server\MSSQL11.SAMPLES\MSSQL\DATA>dir programmingefdb2*
Volume in drive E is JET20110708-1
Volume Serial Number is EA22-1F7C
Directory of E:\Program Files (x86)\Microsoft SQL Server\MSSQL11.SAMPLES\MSSQL\DATA
08/09/2013 11:39 AM 10,485,760 PROGRAMMINGEFDB2_Data.mdf
08/09/2013 11:39 AM 1,310,720 PROGRAMMINGEFDB2_Log.ldf
2 File(s) 11,796,480 bytes
0 Dir(s) 250,238,443,520 bytes free
Here is the directory after making the connection in the VS project but without even trying to run the update code (and without copying the DB into the project):
E:\Program Files (x86)\Microsoft SQL Server\MSSQL11.SAMPLES\MSSQL\DATA>dir programmingefdb2*
Volume in drive E is JET20110708-1
Volume Serial Number is EA22-1F7C
Directory of E:\Program Files (x86)\Microsoft SQL Server\MSSQL11.SAMPLES\MSSQL\DATA
08/09/2013 11:51 AM 10,485,760 PROGRAMMINGEFDB2_Data.mdf
08/09/2013 11:51 AM 516,096 PROGRAMMINGEFDB2_Data_log.ldf
08/09/2013 11:39 AM 1,310,720 PROGRAMMINGEFDB2_Log.ldf
3 File(s) 12,312,576 bytes
0 Dir(s) 250,237,927,424 bytes free
To anyone reading this thread and especially to the author, I found the solution over on the MS SQL Server forum. Here is the answer:
Visual Studio corrupting SQL Server logfile
I have been asked to create an MVC web application in VS 2010, and was instructed to use a SQL express database for my data. I am using EF Code-First for creating and managing my data. The database was created in VS2010, and is attached via "AttachDBFilename" in the web.config.
I have used SQL CE before with MVC with no problems, however the attached SQL Express DB is causing weird issues.
For one thing, when I try to deploy the app, it fails and tells me that it cannot copy the database.mdf because it is in use by another process. I have NOT opened the database in VS2010 nor SSMS. Of course the program code accesses it - is there some reason that connection would remain open? I am using boilerplate code from the scaffolding.
I should mention that I use a ProjectInitializer.cs to create the sample data. It runs at every launch for the moment, since I am testing quite a bit.
The other problem I have is that if I delete the database, it fails to recreate it. It says that my windows account does not have access to the (now non-existent) database that it is trying to create. I literally have to create a new database with new name, as anything that was created previously (with that DB name) fails.
I assume there is some sort of residual info being left somewhere that is out of synch, but I don't know what it is. I've closed all connections to the file in VS 2010, deleted the files, both any found via VS2010 and any physical files I see in the app_data directory.
Any help or suggestions would be appreciated.
Shut down the web server (Cassini, IIS, IIS Express) and try again. The file can remain locked if the web process is still referencing the file. In addition the loaded EF context will retain the db name. Ensure the visual studio browser isn't running in the tray still either.
I created SSIS packages a while ago, today I need to re-point them to a different SQL server. I have a bunch of "Execute SQL Task" tasks, which need their Connection property changed to a different server.
I created a new connection manager, double-clicked on each of the sql tasks, changed their Connection property to the new one, ran. It failed, the error was that it could not find the old connection. I restarted the project, none of the SQL Server tasks seem to pick up the new Connection Manager. I opened up the .dtsx files, tried to find the old server name somewhere and manually change it, but I could not find the old server.
What do I have to change to get rid of the old SQL Server and make it connect to the new, correct data source.
I work in VS2005, on Windows 2008 x64 machine (I don't know if it matters or not).
Thank you.
I've seen this occur before when Package Configurations are enabled. Make sure that this is not the case, recompile, and try again.
all you had to do is change the connection string in the old connection manager
make a new one if you deleted the old one and in all the tasks select the new one, even if you create a new one with the same name as the old one it won't work because somewhere internal a guid is used
Check to see if package configuration is enabled. The package may still be getting the configuration of the old server from the package configuration.
try recompiling after making the changes.