I had created a webpage with DB access which works perfectly well on the machine I develop it. However, when I copy everything across to another machine, it fails with an error message - cannot open database xxx requested by the login. I did copy everything including the database created in the development environment and put it in the same place as the development did. What other thing I had done wrong ? Please help. In addition, when I open the solution on another machine, I cannot see the database from the SQL Server Object Explorer like what I saw on the development machine.
Problem solved ! Need to copy the database and the log file across and the used the SQL Server Manager to attach the database to the right server. After that, everything just work !!
im using MS-access as my database. I've already finished the project and it is working perfectly fine.
my database location while im still developing is in C:\Users\Users\documents and the other one located at C:\Users\Users\documents\visual studio 2010\projects\project1\project1\bin\debug
is bad to put the database at two different folder?
1st problem: now creating a setup and deployment project, i use setup wizard and checked all then build it. installation of setup is successful but when i try to run the program, it doesnt respond,
2nd problem: i cant see my 1st database located at program files, only the second one and maybe this is the cause of unresponsive app.
copying the debug files into other computer and copying manually my database to user\document which i have to change permission and the copied debug files runs well, but i have to create an installer. how to do it?
from my server explorer i was wondering there is only one database, yet my program works fine when running debug? reconnecting the unseen database would be a lot of work because it is my main database.
You should check the database which is connected to your project and the path which is associated.
Try Application.StartUpPath in your connection.
Box was corrupt and was cleaned up and operational. Now, SQL Server will not connect to my db. I checked services and found that mssqlserver, SQL Server agents won't start. Gives error
Cannot connect to local server
They are set to automatically start, but manually starting gives the same error.
I cleaned his box with this recipe that I use successfully on dozens of computers. All other software is running fine. His box also had a failing disk so I xxcloned (XXClone.com) his disk to a fresh new disk. I believe the cleaning is an unrelated issue, but whatever it takes to fix it we are happy to try. I know many people with this SQL Server issue, and over the years have fixed it a few ways, but I am tight on time, so I suggested he get help here.
THOROUGH BADDY CLEAN. Clean a Windows Machine without Formatting it or losing Data
STEP 1
If Ransomware or some baddy is taking over our MBR or Partition so you cannot escape it, and cannot run safe mode, the ICE Ransomware being one of many examples.....
http://www.bleepingcomputer.com/virus-removal/remove-ice-cyber-crime-center-ransomware
use a empty USB stick and HitManPro (the free version will remove)
http://www.surfright.nl/en/hitmanpro/
STEP 2
Reboot in Safe mode with networking by rebooting and holding down F8 key. None of this will permanently fix your computer unless you are in SAFE MODE w/ NETWORKING
Download RKill and run it
Download ComboFix from BleepingComputer.org and run it
Download SmitFraudFix and run it
Download AntiMalwareBytes to catch everything those did not
I can clean any machine no matter how badly infected with these tools in safe mode. Will keep recurring if attempted in Normal Mode. Safe mode is the key.
After installing SP2 to an existing SQL Server 2008 R2 I lost access to all my databases and started facing the error in the screenshot.
Any ideas?
Check the environment value for Temp and TMP.
C:\Users\buck>set t
TEMP=C:\Users\buck\AppData\Local\Temp\2
TMP=C:\Users\buck\AppData\Local\Temp\2
Make sure the directory listed exist and your id has appropriate permission to write to that directory. Alternatively, through the control panel (Control Panel-> System and Security-> System -> Advanced system settings), you can change the default directories that are assigned to TEMP and TMP.
When I've seen this issue, it is usually because the Drive that SSMS is installed on has run out of free space. Deleting some old Log files clears the issue up.
Doing that quick check might be worthwhile before going forward with a re-install.
I got this error on our remote shared server. Turned out that our C drive did not have any space left.
I got it working by asking my colleague to close his SQL Server Management Studio session and it cleared up 7 GB right away! I could login then! Woot woot!
Right click on the SSMS icon and click 'run as administrator'. At the SSMS console verify that the error is gone by clicking on the 'Databases' tree node. The error should now be permanently fixed and you do not need to run SSMS as admin anymore. Next time just start SSMS normally and it should work fine.
Changing the temp variables did not resolve. Drive with SMMS installed has 34% free space.
However, using Run > %temp% > it would error out as "C:\%username%\appdata\local\temp\4 was missing" (this is not listed in my TEMP/TMP variables).
Quick solution was to add sub folder for "4" in c:\%username%\appdata\local\temp\ and now able to open SMMS without issue.
When running into this I found it was related to the environment temp folder (TMP Temp).
I had tried adding the "2" folder to this location with no success.
C:\Users\USER\AppData\Local\Temp\2
Try typing %temp% in file explorer and see if it takes you to a valid location. I found that I received an error because it was trying to go to a "4" location.
C:\Users\USER\AppData\Local\Temp\4
I created a folder named "4" in the Temp folder, reran SSMS, and it started working again.
A quick google suggest that apparently it is a bit common issue. It looks like that it is not an issue of SQL Server itself but actually .NET issue And most common (and quick) solution I found is to reinstall SSMS.
I've found that if you are upgrading an iseries odbc driver on a sql cluster. Lots of times you will run into this issue exactly. Renaming the machine.config in both the 32 bit and 64 bit folders does the trick. we currently upgraded from version 12 or 6.1 to 7.1 or 13 as the version 12 was causing a bug check on one of our SQL instances. Upgraded, and the issues all went away.
Cheers,
According to the following link:
https://connect.microsoft.com/SQLServer/feedback/details/573771/value-cannot-be-null
I just checked that my user is local admin, then i logged off and logged back in.
After that step i haven't received this error again.
I was receiving this exact error and thought I'd have a go at running the repair.
Well the repair didn't resolve the issue however it did tell me that it was unable to access machine.config in C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG - found it didn't exist! There was another file machine.config.default
So had a stab at copying, renaming to .config and viola resolved it and everything working like a champion.
I got the same error in SSMS and I found this link and followed the steps as it mentioned.
The problem appeared to be when accessing the contents of a settings file. The file had invalid entries. This file is CurrentSettings-. The fix for this is as shown below:
On the server Go to start menu–>Your profile–>Documents–>SQL Server Management Studio–>Settings (this is the location of the file specified above)
Delete all files from this folder
Restart sqlserver services
Launch the SSMS and this error is gone. You will be able to expand all the folders and perform regular SSMS activities without this error.
Once I performed these steps and restarted my PC this error was gone and SSMS worked fine.
I just faced this issue and resolved it immediately in 5 mins. Just go to Control Panel and Run Troubleshooting tool on Programs.
**PATH** Control Panel\All Control Panel Items\Troubleshooting\Programs
It will give you the list of installed programs which may have any issue. Scroll down that list and find 'SQL Server Management Studio' and run troubleshooting process on that. It will hopefully fix you issue.
I gets this messages many times and every time it is resolved by different solutions below few of it.
Solution: Clear cache from temp folder, Press windows + R => type "%temp%" => Delete all the files from temp folder... And try weather it works and opens ssms successfully
Solution: create folder named "2" in this above mentioned temp folder location... And try weather it works and opens ssms successfully.
Solution:create folder named "4" in this above mentioned temp folder location... And try weather it works and opens ssms successfully.
Solution: It may cause because of low disk space in drive ssms is installed... so free some space...And try weather it works and opens ssms successfully.
Solution: Format is the last solution...
I have a VB based VS2005 appl developed using Access DB a few years back on Windows XP and it has been working fine until moving to Windows 7. I re-built the solution by changing to the x64 platform also at the sametime modified the Access DB a bit resulting in a new Access DB file to be included in the solution. When I debug in VS2005, I have the new version of DB residing in my project\x86\Release folder and successfully access this new version.
Problem is that once I create the solution for deployment, the deployed application kept on opening the OLD version of the access database (mdb) file. I was not able to find where is it opening the old version of DB from even after I removed the mdb from the installed folder. I have been a lot of digging and research on web and not able to find out how to solve this problem.
Can someone please help to tell me how I can have my deployed appl to open the new version of DB ?
Thanks in advance
It sounds like you are not allowing for virtualisation - do you know about this? For security reasons after XP (Vista onwards) Microsoft doesn't allow writing to the Programs folder and if it encounters an application attempting to do this makes a copy of the files trying to be written to (in your case an Access database) and places it somewhere (can't remember exactly where at the moment) hidden from casual user.
For example, if you look at the database on your Win 7 machine in the same location at your .exe file I should think you will find it is unused - and since it was installed on the machine the OS has been redirecting requests to read/write to your database to the virtualised copy it created for you.
So, first of all find this other copy (sorry I'm currently on a mac and can't remember the location) and see if that contains data that your application is creating. Then try substituting your new database (making a a copy of your old one first of course) and seeing if your application is reading/writing to it OK.
Then it is a matter of handling replacement of databases during application installation.
However, you should give serious consideration to placing your database in a location which is not virtualised!