Marina
Tue Aug 22 12:08:18 CDT 2006
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.
"Cor Ligthert [MVP]" <notmyfirstname@planet.nl> wrote in message
news:euGMjugxGHA.2264@TK2MSFTNGP02.phx.gbl...
> 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]" <someone@nospam.com> schreef in bericht
> news:OHqqVkgxGHA.1872@TK2MSFTNGP05.phx.gbl...
>> 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]" <notmyfirstname@planet.nl> wrote in message
>> news:uGxWqggxGHA.4140@TK2MSFTNGP03.phx.gbl...
>>> 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]" <someone@nospam.com> schreef in bericht
>>> news:ez6VOSgxGHA.980@TK2MSFTNGP04.phx.gbl...
>>>> 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.
>>>>
>>>> "Ausclad" <Ausclad@discussions.microsoft.com> wrote in message
>>>> news:74F87A45-C935-478D-B49B-78983841904F@microsoft.com...
>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>