dataset safety?

[Guest]

Hi,
I am currently looking at re-writing a payroll/timesheet application that
is currently in Access. The users need to enter timesheet hours for numerous
employees.

Up till now I have been experimenting and using strongly typed datasets as
generated by VS. However as these provide a disconnected model, how can I
prevent the loss of user data if the user PC crashes or dies for whatever
reason.

I imagine it would be inefficient to be performing writes to the database
using datasets after every record is inserted.

I like the binding and coding efficiency of using strongly typed datasets,
however it would seem like there can be big overheads and risk in not
updating to the database regularly.

Can anyone recommend a better way?

thanks

 

[Cor Ligthert [MVP]]

Ausclad,

It is up to you how many times you update the database, be aware that only
changed rows are updated, not a complete dataset. As well can you ask in
advance if a dataset has changes. ds.HasChanges.

The problem lies in the fact if you use an autokey. That is in OleDb
standard not updated by an update in a dataset if that is new. If you use a
Guid as key is this problem gone. AFAIK is this problem gone as well with
SQLClient (I use no auto keys).

I hope this gives an idea,

Cor

 

[Marina Levit [MVP]]

Well, this really has nothing to do with datasets, does it?

This just sounds like a problem of whether or not you batch updates to the
database.

I would argue that if the user did not cilck Save, and their PC crashed,
then it's reasonable that they lost all their work.

If this isn't acceptable, then yes, the more often you go to the database to
auto save changes, the more network traffic you will create. I don't think
this has anything to do with whether you use datasets or something else.

 

[Cor Ligthert [MVP]]

Marina,

This is one of the not often happening situations we don't agree.

I don't think that more updates (with the exception when used auto keys)
will create more (in a real recognisable way) network trafic. The only thing
that you do more, is creating connections.

More trafic can only be if a user is regulary updating a datarow more than
once.

Cor

 

[Marina Levit [MVP]]

Well, if the application is a client/server type application, then the
client has to send the update to the server. Then the server has to go to
the database to do the update.

If this is a web application, you have extra trips to the server as well, so
the server can go to the database.

Either way you are talking about more round trips to the server, and the
server going to the database.

Whereas if you batch up your inserts, you have 1 trip to the application
server with all 10, it opens up one database connection, and adds all 10 at
once.

 

[Cor Ligthert [MVP]]

Marina,

That there are more rountrips is where we agree again about, but the
roundtrips have a lower load.

In my idea is the transport on the network (even more on ethernet because of
posible collisions) that makes a network slow, not the times you use it.
Beside where that is often good recognisable on collision detect type of
neworks, gives in my opinion small transports on every network a better
performance.

Beside that is dataset/datatable update in my idea done row by row from the
rows, that have a "changed" rowstate. That means in my idea that the
connection stays longer open with a lot of updates than that the dataset
contains one changed row. Maybe interesting to test someday.

Just my thought.

Cor

 

[Marina Levit [MVP]]

The company I work for has a web app, and there were significant performance
problems when every request for data made a separate round trip. Once they
were batched up, performance improved significantly, even though the same
amount of data was requested and brought back. It seemed like there was
significant overhead with having 10 small trips, instead of 1 large one.

I think in both our scenarios, only changed rows would ever be sent up with
changes.