Im making a simple application in C# using Visual Studio and WinForms.. I’m using SQLite as my database.. When I use the Run feature within Visual Studio, everything works 100% beautifully.. The problem arises when I install my program onto another computer.
When I install and run my program in another computer, at first, everything works great. Things that require select statements work perfectly.. However, when I try to do something that adds a row to a table or modifies an existing row, my program crashes with the following error: “Attempting to write on a Read-Only Database.”
Upon doing some research online, I realized that this error wasn’t 100% accurate. The database is read-write.. However, the folder containing the database is read-only. So I guess I have to move my database from this read-only folder, to a read-write folder somehow.. How do I go about doing this? Which folder is it in currently, which folder should I move it to, and how do I prevent this move from causing any errors?
This answer identifies the problem, but doesn’t give a clear solution:
https://stackoverflow.com/a/16068894/10216226
Please help me out! I’m at the final stretch of developing this application and I really would love to have this completed!
Thanks!
Related
I created a project in Unity, work a little bit on it. And then I tried to delete one of the scripts I created earlier, but every time I try to delete it a message shows up:
Fatal Error!
attempt to write a readonly database
UnityEditor.DockArea:OnGUI()
I tried to delete the file manually from the folder, but it caused similar error every time I launched Unity.
All the googling did not help me as long as all the answers are for the Windows, where permissions are easy to set up. For OS X only one answer was found, which said to make a folder shared, which also didn't help.
Does anyone know the solution of that?
I get this crash whenever I am trying to delete a file from my project or trying to create a build in unity. I am using a mac running sierra OSX (though I expect that won't matter) but the primary issue, is due to limited internal hard drive space, I had the project saved on an external SSD drive plugged into my mac. This seems to be the main issue. If your running into this issue and you have a similar setup, try copying the project file over to your onboard hard drive and operating it from there.
I have not yet found another solution around this problem. For some reason unity can save to external drives fine, but doesn't like to delete or build from them.
Try to delete all in folder
/Users/Shared/Unity/4.0_Angrybots/Temp
I use Visual Studio Team Services to store the source code of my projects as I work on them, I love the service, especially that it is free, but I have been running into the biggest pain lately.
Randomly when I go to save, modify, check in check out I get this error for every single file I am modifying. So if I am trying to save changes to 8 files I get this message 8 times and it takes 45 60 seconds of trying to check out for each file meaning to takes 6 - 8 minutes for the errors to stop (even if I hit cancel).
The local data store is currently in use by another operation
I looked it up online and found many people with the same issue but the response from MS has nothing to do with my situation.
http://blogs.msdn.com/b/phkelley/archive/2013/05/31/tf400030-the-local-data-store-is-currently-in-use-by-another-operation.aspx
It basically says this can happen when you have to many files in your workspace or have several large solution open at once.
This does not apply to me as I usually only have on solution open at a time and my projects are very small (400 -500 files).
Ran into this issue as well on VS 2013 and TFS - every time I opened my team explorer it would take 10+ seconds to show all projects, then when I would expand the project in source control, another 10+ seconds would roll by.
Earlier today I began to experience the "local storage is being used" error when trying to save data in class files. I did some original research, and this following link saved the day for sure. Now TFS is blazing!
Local Data Store Solved
What you do is edit workspace (including all projects associated), and change the "Location" dropdown from "Local" to "Server". It took about 4-5 minutes for the changes to finish, but well worth it.
Hopefully this will help someone down the road.
Lately I started to get same error message and Visual Studio started to work very slow with TFS and nuget. I have tried repair and uninstall but not solve the problem. At the and it was so painfully slow that I cannot continue working. (Expanding one item on source control explorer takes 10 seconds)
Here is my story and how my problem be solved:
I was mapped tfs folders separately not to get whole TFS because there are lots of irrelevant documents. After trying lots of fix suggestion, I thought this might be the problem because I did this separate mapping first time while I have been using TFS. I generally map and get all items at once and never met this issue before.
I removed all mappings and it was like magic. Error is gone, slow TFS source control is gone and it is rocket fast now. Just to be in a safe side I also delete my workspaces and create a new one and get all TFS items at once.
I found the error would be triggered when I had more than once instance of VS 2012+ running utilizing Source Control Explorer, Solution Explorer and/or Team Explorer windows. I've not had this problem when running a single instance of VS 2012+ (on updates 2+) utilizing Source Control Explorer, Solution Explorer and/or Team Explorer windows in tandem.
I found this article and gave it's suggestion a shot: to prevent multiple threads from accessing the data store simultaneously.
http://blogs.msdn.com/b/phkelley/archive/2013/05/31/tf400030-the-local-data-store-is-currently-in-use-by-another-operation.aspx
This proved to be a remedy for this issue.
I would add for other users with large file repositories, using source control and share this issue, it may be greatly beneficial to create multiple workspaces for each of your branches/repositories. I found that by doing this my queries to TFS sped up immensely and also helped with this error. I found this suggestion here: http://blogs.msdn.com/b/phkelley/archive/2013/05/30/using-multiple-workspaces-with-visual-studio.aspx. I share this as users mention TFS running slowly.
I also started getting the same error this week. Maybe there's something wrong with VS Update 3?
Simply could not work on any of the projects of the "broken" local workspace anymore.
VS would show all files as being checked out, but none were really.
Other local workspaces were working fine.
I tried removing a project from the workspace, but when trying to confirm it, I would receive the same TF400030 error again.
Suggestion
If nothing else works, you might want to try this: simply delete the whole workspace and create it again, this time separating projects into different workspaces. This worked for me.
You'll probably want to back up your files first.
I did as mentioned below and TFS started working fine
Close all the VS instances
Go to: C:\Users[UserName]\AppData\Local\Microsoft\VisualStudio\15.0_46af8b8e
Delete the privateregistry.bin file
Reopen the project solution
Above worked for me.
Had the same problem,can be fixed in 3 quick steps:
Remove current Workspace: Source Control Explorer->Work Space ListBox->workspaces... and remove the workspace.
- Make sure that all pending changes are checked in
Delete Workspace local folder.
- Its Better to delete the folder entirely.If eventually keeping some folders make sure to delete all $tf folders (hidden folders inside the workspace folder)
Remap the projects you need ( the less the better )
Hopes that helps.
In my case the cause was a compressed folder containing my local data store, shown in blue in Windows explorer. Removing the compression did the trick.
I ran into this error when renaming my workspace. After changing back to original everything worked fine again
Restarting the Visual studio resolved the issue for me.
Additional info: I thought it might be helpful to say that my forms and classes are in the same solution as the already updated forms.
In our company we have this project which 3 people are working on it. One works on the database part, me and another colleague of mine are working on making the UI ready and relating it to database which is MS SQL Server 2012 and we are programming in C# in VS 2012.
The problem is that I made this one form ready, but the server version is ahead of me. That is, if I check in the whole program, I will damage the project as some forms has changed and the version I have is older. I tried right clicking and checking in only the forms and classes which I, myself made and I have their latest version. They check in without any error or anything, but the problem is, when my colleagues or myself(after deleting my source project) try to get latest version, my forms or classes doesn't show up.
We also tried to check in the whole program but only accept those pending changes which are made by me, still no success.
The problem is, we are kinda afraid to play with the server version as a lot of effort has gone into it.
Any help will be really appreciated as I'm stuck with this problem and the manager won't give me more parts of the program to make until we can come up with some way to deal with this.
You haven't mentioned merging at all but I think this is the answer to your question.
When you work on an older version of the code (because your local code is older, or maybe the whole branch of the code is older), you need to merge the code into the newer version. When you merge, any potential conflicts are detected and you can resolve all of them manually. There's obviously tools to help you - one is built into Visual Studio but you can replace it with an external tool which may work better for you. Either way, you need to decide how to merge the code. You have a few options:
take the whole code from the source (old code in this case),
take the whole code from the target (new code in this case),
merge the changes and take bits from each version based on your knowledge of the changes and how the code should look like.
As for why the forms don't show up, you probably didn't check in the changes to the project file so the new files are not part of the project as it exists in Team Services.
I have a very odd situation where by changes committed to the repository by my colleagues when updated to my local copy of the software, Visual studio doesn't recognise them immediately, and reload. the result (and this is very odd) is that most of the times, I will save my changes without the reloaded projects and will overwrite my colleagues changes. It is so embarrassing that sometimes I am asked why I had to change a piece of code and in reality I hadn't.
Another thing is, when I check in some VS project level changes like when someone added a new class, or form or anything and continue to work in Visual studio, it will take me at least 5 to 10 minutes before I get the warning that there was some changes and be asked to reload the project etc...
I think there should be a setting somewhere in visual studio to trigger an automatic reload, but can't find it.
This affect me and another person so far but mine is the strangest as it can take up to 30 minutes before a project start reload.
Any Ideas welcome
This is my settings
If you are working using Source Control, you will need to synchronise your local workspace with the server ("get" the latest code) before any changes by your colleagues will be copied to your PC.
If you don't "get" the latest code before you make changes then you may have to merge your changes with somebody else's, which can be a difficult, time consuming or even dangerous process - especially if you use the default Visual Studio automatic merge process, which usually does the wrong thing, resulting in essentially corrupt code (making it look like you deleted your colleague's works, just as you are describing, for example).
The best way to work with source control is the "little and often" approach:
Get the latest source code before you start any new work, so that your PC is as up to date as possible.
It's usually a good practice to "get" the latest code frequently (e.g. I do it first thing every morning) so that any merge conflicts are flagged up and dealt with as early as possible. The longer you wait before merging the worse the merge process tends to get. (Caveat: Check with your build system that the current version of the code on the server is working before you get it - you don't want to get broken code onto your PC as it may stop you being able to work at all).
Arrange your work as many small incremental steps that can be safely checked in as they are completed (rather than working for 3 months on hundreds of files and then dumping it on the system as one massive change )
When you are ready to check in, get the latest code, rebuild, and re-test your changes to be sure they still work when integrated with the latest program code. Only check in if everything works well.
Also be aware that when you try to edit a file, the source control provider may automatically "get" the latest version of that file for you (which could cause Visual Studio to tell you it has reloaded the file, and perhaps explain why you say it sometimes takes a while to "update", as it doesn't happen until you start editing a new file that has been changed recently by someone else). If this is the case, then the truth is that you have not "updated" the entire set of source code, only one file - in this case you really need to get all the latest changes to the source code (if you don't you may find it is uncompilable or (even worse), compiles but exhibits undefined behaviours due to only part of the code being up to date)
Lastly, a very good practice when checking in your code is to go through the list of files you are checking in and diff them one by one against the latest server code to see what you have changed. This may sound laborious but it confers several benefits:
It reminds you what you did, which can sometimes be helpful for filling in the check-in comment to clearly describe all your changes and make sure you don't miss an important note.
You will easily spot anything that has been screwed up in the merge process - there will be chunks of code that appear to be created or deleted that you know you didn't touch. So you'll be able to discover and fix these problems before you check in rather than annoying your colleagues by "deleting" their changes.
I find this very useful for finding temporary debugging code that I have forgotten to take out before I check in.
Sometimes you may even do a double-take on a bit of code you are about to check in and think "huh? why did I do that?". And then you might decide to re-examine and possibly even rewrite the code you thought was good to go.
Final Note: The options you show in your edit only relate to changes that are made to the files on your PC by another program on your PC. If another user makes a change and checks it in to source control, these options will have no effect. It is only when your Source Control system copies those changes to your PC's hard drive that you might see Visual Studio reacting to those changes (depending on how well your source control system is integrated with VS).
If you're sure the problem is Visual Studio (e.g. the file really has changed on the disk but you don't see it in Visual Studio)
Make sure that the Detect when file is changed option is checked.
Tools > Options > Environment > Documents > Detect when file is changed outside the environment
Since you are sometimes getting an alert to reload your project due to external changes means you already have the settings required to detect file changes in Visual Studio.
However, reloading of project/solution will only be triggered if the .csproj (or .vbproj) or .sln file was changed.
By the way, are you using some version control system? It seems that you are just sharing the solution and editing simultaneously.
This is really weird behavior, let's say I have an asp.net mvc project as follow on my desktop (vista):
/mvcapplication/app1
then over the course of development, I copy this solution to a briefcase on a thumbdrive so I can work on it from a laptop (xp).
When I insert the thumbdrive back on the desktop, I notice it's taking longer and longer to sync, eventually it took so long that it just hangs there. I checked the project structure and found that it is now:
/mvcapplication/app1/app1/app1/app1
with each /app1 containing the entire project structures. I am not new to visual studio, and I am sure I opened and saved the solution and files just as I normally did, but this is just bizzard. I thought this is caused by briefcase, but the same thing happened when I copied the solution into a folder on the thumbdrive.
I would have left this alone, but with that sort of crazy folder structure it's really difficult to determine which folder has my current changes..
Anyone ever run into something like this?
Never had this happen but then I don't use the Briefcase. Then again, I try to avoid most things in Vista.
I just use good 'ol copy and past for thumb drive stuff.