Radi:
The first thing to look at is to ensure that you Adapter is configured
correctly for Updates. Are you using the configuration wizard, the
commandbuilder, the enterprise library or did you write your own. If you're
using the Visual tools , make sure that all of the commands were generated
correctly at the end.
If they are, then you need to check the Rowstate of each row. When you call
Update, the adapter loops through the rows and checks the rowstate. If the
rowstate is deleted, then it uses the Adapter's Delete command and after
submitting the update, calls AcceptChanges on the row which resets the
rowstate on the row. It does the same for Inserts and Updates. However, if
you don't have Changes in your rows, then nothing gets submitted to the
server. One way to verify that is to trap the StateChanged event of the
connection and pop up a messagebox when the state changes. if you don't see
a messagebox then nothing go sent back tot he server (in Sql Server as
opposed to access, you can use Profiler but since you're not using Sql
Server, I just mention it in passing). The better way to check for changes
is to use Debug.Assert(dsPersonal1.HasChanges, "No Changes Are Present");
right before you call Update. If the assertion passes, then you have changes
and if the DB isn't getting updated, then the problem is almost certianly
with your commands themselves. If the assertion fails, then the problem is
that the UI isn't updating as you expected and more than likely, you need to
End the current edit of the row. You do this differently depending on how
you're binding things.
So first, verify that you have correct commands and more importantly, verify
that you have changes to be sumbitted. 99% of the time it's one or both of
these issues. if it isn't, let me know and we'll take it from there.
Cheers,
Bill