Why saving changes to a database fails?

后端 未结 2 1284
予麋鹿
予麋鹿 2020-11-21 05:51

I have following C# code in a console application.

Whenever I debug the application and run the query1 (which inserts a new value into the database) and then run que

相关标签:
2条回答
  • 2020-11-21 06:39

    Committing changes / saving changes across debug sessions is a familiar topic in SQL CE forums. It is something that trips up quite a few people. I'll post links to source articles below, but I wanted to paste the answer that seems to get the best results to the most people:


    You have several options to change this behavior. If your sdf file is part of the content of your project, this will affect how data is persisted. Remember that when you debug, all output of your project (including the sdf) if in the bin/debug folder.

    • You can decide not to include the sdf file as part of your project and manage the file location runtime.

    • If you are using "copy if newer", and project changes you make to the database will overwrite any runtime/debug changes.

    • If you are using "Do not copy", you will have to specify the location in code (as two levels above where your program is running).

    • If you have "Copy always", any changes made during runtime will always be overwritten


    Answer Source

    Here is a link to some further discussion and how to documentation.

    0 讨论(0)
  • 2020-11-21 06:45

    It is a quite common problem. You use the |DataDirectory| substitution string. This means that, while debugging your app in the Visual Studio environment, the database used by your application is located in the subfolder BIN\DEBUG folder (or x86 variant) of your project. And this works well as you don't have any kind of error connecting to the database and making update operations.

    But then, you exit the debug session and you look at your database through the Visual Studio Server Explorer (or any other suitable tool). This window has a different connection string (probably pointing to the copy of your database in the project folder). You search your tables and you don't see the changes.

    Then the problem get worse. You restart VS to go hunting for the bug in your app, but you have your database file listed between your project files and the property Copy to Output directory is set to Copy Always. At this point Visual Studio obliges and copies the original database file from the project folder to the output folder (BIN\DEBUG) and thus your previous changes are lost.

    Now, your application inserts/updates again the target table, you again can't find any error in your code and restart the loop again until you decide to post or search on StackOverflow.

    You could stop this problem changing the property Copy To Output Directory to Copy If Newer or Never Copy. Also you could update your connectionstring in the Server Explorer to look at the working copy of your database or create a second connection. The first one still points to the database in the project folder while the second one points to the database in the BIN\DEBUG folder. In this way you could keep the original database ready for deployment purposes and schema changes, while, with the second connection you could look at the effective results of your coding efforts.

    EDIT Special warning for MS-Access database users. The simple act of looking at your table changes the modified date of your database ALSO if you don't write or change anything. So the flag Copy if Newer kicks in and the database file is copied to the output directory. With Access better use Copy Never.

    0 讨论(0)
提交回复
热议问题