none
My Update statment don't affect to database file.help me RRS feed

  • Question

  • Hello

    I write a RssFeed Reader with Vb.net(Application) and In run time when I Refresh it and update the dataset to database with data adapter, it's work, but when I shutting down the application and rerun it, the database have no change and data is same data when I save it to database manually.

    Friday, April 30, 2010 10:04 AM

Answers

  • Hi Masoudshirzadi,

    You can refer to the following article to see if you have the same problem.

    FAQ: My database isn't being updated, but no errors occurred in my application

    Problem:

    You have an ADO.NET application that updates, inserts, or deletes data from your database. No errors occur and the data changes are visible in the application, but do not persist between application runs, or if you view the database file outside of the application.

    Solution:

    There are two common reasons why this happens:

    (1) You are calling AcceptChanges on your DataRow/DataTable/DataSet before you call Update on your DataAdapter or TableAdapter. AcceptChanges will commit all changes made since the data was loaded or since AcceptChanges was last called. This means that if you had a row that was marked as Modified, it will now be Unchanged. When you call Update, it will not recognize that the row has changes that need to be submitted to the database. The same applies for inserted and deleted rows as well. For more information, see the AcceptChanges documentation: http://msdn2.microsoft.com/en-us/library/system.data.dataset.acceptchanges.aspx. This applies to all database backends and application types (ASP.NET, Windows Forms, etc).

    (2) The other common problem is that in Visual Studio, there is an option to copy your database file to the output folder of your project. Usually this is done with an Access MDB file, or a SQL Server MDF file, when you add the database file to your project.

    This copy options applies each time you run the application. Therefore, although the database may in fact be updated, the updates are going to the copy instead of the original file that you expect. The key to this is the “Copy to Output Directory” property on the database file in your project. This is typically set to “Copy always” by default. What this means is that every time you build, run, or debug your application, Visual Studio copies the project file over to the output directory, and then that’s what the app connects to.

    In these cases, you will probably also be using a connection string that includes the "|DataDirectory|" option. For non-Web apps, this is the project output folder where your executable is created (usually bin\debug). In order to ensure that this connection string will work, Visual Studio chooses the "Copy Always" setting by default. You can keep the connection string as-is, but change the copy option to "Do not copy", and in that case, you should see your changes persist between application runs, or if you check the database outside of the app. Make sure to check the copy in the output folder. Alternatively, you can change the connection string *and* the copy property, and point to the file you actually want to connect to.

    This applies to Access MDB files, as well as SQL Server MDF files, as long as you are connecting to the MDFs file at runtime by specifying the location in the connection string with the AttachDBFilename keyword. Access databases are always file-based, so there is no need for a special keyword.

    There is a utility you can use to see which database file is actually being used by the application: FileMon by http://www.sysinternals.com. Start tracing before you run your application, then watch to see which file is actually accessed. Keep in mind that the trace may also include any file copies, so make sure you search for all occurrences of your filename, to be sure that all of them are using the file you expect.

    Best regards,
    Alex Liang

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Proposed as answer by Gopi V Tuesday, May 4, 2010 9:51 AM
    • Marked as answer by Alex LiangModerator Friday, May 7, 2010 6:50 AM
    Tuesday, May 4, 2010 7:05 AM
    Moderator

All replies

  • Hi there, some example code would be useful here. It sounds like an update is missing somewhere or that you have called AcceptChanges() etc.

    //Michael


    This posting is provided "AS IS" with no warranties.
    Friday, April 30, 2010 10:26 AM
  • We have seen this when the database file is included in the project and it's set to overlay the Debug/Production version when the application is restarted.


    __________________________________________________________________
    William Vaughn
    Mentor, Consultant, Trainer, MVP
    http://betav.com
    http://betav.com/blog/billva
    http://www.hitchhikerguides.net

    “Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)”

    Please click the Mark as Answer button if a post solves your problem!

    Friday, April 30, 2010 4:55 PM
    Moderator
  • Hi Masoudshirzadi,

    You can refer to the following article to see if you have the same problem.

    FAQ: My database isn't being updated, but no errors occurred in my application

    Problem:

    You have an ADO.NET application that updates, inserts, or deletes data from your database. No errors occur and the data changes are visible in the application, but do not persist between application runs, or if you view the database file outside of the application.

    Solution:

    There are two common reasons why this happens:

    (1) You are calling AcceptChanges on your DataRow/DataTable/DataSet before you call Update on your DataAdapter or TableAdapter. AcceptChanges will commit all changes made since the data was loaded or since AcceptChanges was last called. This means that if you had a row that was marked as Modified, it will now be Unchanged. When you call Update, it will not recognize that the row has changes that need to be submitted to the database. The same applies for inserted and deleted rows as well. For more information, see the AcceptChanges documentation: http://msdn2.microsoft.com/en-us/library/system.data.dataset.acceptchanges.aspx. This applies to all database backends and application types (ASP.NET, Windows Forms, etc).

    (2) The other common problem is that in Visual Studio, there is an option to copy your database file to the output folder of your project. Usually this is done with an Access MDB file, or a SQL Server MDF file, when you add the database file to your project.

    This copy options applies each time you run the application. Therefore, although the database may in fact be updated, the updates are going to the copy instead of the original file that you expect. The key to this is the “Copy to Output Directory” property on the database file in your project. This is typically set to “Copy always” by default. What this means is that every time you build, run, or debug your application, Visual Studio copies the project file over to the output directory, and then that’s what the app connects to.

    In these cases, you will probably also be using a connection string that includes the "|DataDirectory|" option. For non-Web apps, this is the project output folder where your executable is created (usually bin\debug). In order to ensure that this connection string will work, Visual Studio chooses the "Copy Always" setting by default. You can keep the connection string as-is, but change the copy option to "Do not copy", and in that case, you should see your changes persist between application runs, or if you check the database outside of the app. Make sure to check the copy in the output folder. Alternatively, you can change the connection string *and* the copy property, and point to the file you actually want to connect to.

    This applies to Access MDB files, as well as SQL Server MDF files, as long as you are connecting to the MDFs file at runtime by specifying the location in the connection string with the AttachDBFilename keyword. Access databases are always file-based, so there is no need for a special keyword.

    There is a utility you can use to see which database file is actually being used by the application: FileMon by http://www.sysinternals.com. Start tracing before you run your application, then watch to see which file is actually accessed. Keep in mind that the trace may also include any file copies, so make sure you search for all occurrences of your filename, to be sure that all of them are using the file you expect.

    Best regards,
    Alex Liang

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Proposed as answer by Gopi V Tuesday, May 4, 2010 9:51 AM
    • Marked as answer by Alex LiangModerator Friday, May 7, 2010 6:50 AM
    Tuesday, May 4, 2010 7:05 AM
    Moderator