DataSet ds = new DataSet();
custDA.Fill(ds, myTableName);
//изменение данных
custDA.Update(ds, myTableName);
custConn.Close();

скажите пожалуйста чем будет отличаться если я закрою коннект а потом перед сохранением открою заново вот так

SqlDataAdapter custDA = new SqlDataAdapter("SELECT * FROM Customers", custConn);
custDA.Update(ds, myTableName);

ну то есть пересоздам dataadapter

Здравствуйте, Аноним, Вы писали:

А>

А>DataSet ds = new DataSet();
А>custDA.Fill(ds, myTableName);
А>//изменение данных
А>custDA.Update(ds, myTableName);
А>custConn.Close();
А>

А>скажите пожалуйста чем будет отличаться если я закрою коннект а потом перед сохранением открою заново вот так

А>SqlDataAdapter custDA = new SqlDataAdapter("SELECT * FROM Customers", custConn);
А>custDA.Update(ds, myTableName);
ситуация простая: чем меньшее время ты держишь открытым соединение — тем выше пропускная способность твоего приложения.
Однако, если "изменение данных" — это пара простых операций, то проще все сделать на одном соединении.
На самом деле, для тебя ничем не будет отличаться если не ставил какие-нить специфические опции на подключении, типа set nocount (для SQL Server) и т.п. — они просто сбросятся, и к тому же не факт, что ты получишь повторно именно то же физическое соединение с БД.
Пересоздание адаптера тоже ничем не грозит. Мало того, скажу по секрету, что адаптеру можно дать закрытое соединение. Тогда он его откроет, сделает свое крамольное дело, а потом закроет обратно.

Здравствуйте, Козьма Прутков, Вы писали:

КП>Здравствуйте, Аноним, Вы писали:

А>>

А>>DataSet ds = new DataSet();
А>>custDA.Fill(ds, myTableName);
А>>//изменение данных
А>>custDA.Update(ds, myTableName);
А>>custConn.Close();
А>>

А>>скажите пожалуйста чем будет отличаться если я закрою коннект а потом перед сохранением открою заново вот так

А>>SqlDataAdapter custDA = new SqlDataAdapter("SELECT * FROM Customers", custConn);
А>>custDA.Update(ds, myTableName);
КП>ситуация простая: чем меньшее время ты держишь открытым соединение — тем выше пропускная способность твоего приложения.
КП>Однако, если "изменение данных" — это пара простых операций, то проще все сделать на одном соединении.
КП>На самом деле, для тебя ничем не будет отличаться если не ставил какие-нить специфические опции на подключении,

нет, никаких специфических опцияй я не выставляю, но дело в том что я работаю через с распределённым приложением:

есть клиенты, есть сервер,
клиенты напрямую общаются с сервером а сервер на прямую с БД

клиент -> сервер(remoting) -> sqlserver

на сервере валяется типизированный DataSet который соответствует базе данных на sql servere...
так вот клиенты добавляют и изменяют записи в этом датасете, и я не могу понять как лучше и надежнее обновлять sqlserverную БД...

зы: клиенты добавляют и изменяют записи довольно часто ... я в замешательстве

КП>типа set nocount (для SQL Server) и т.п. — они просто сбросятся, и к тому же не факт, что ты получишь повторно именно то же физическое соединение с БД.
КП>Пересоздание адаптера тоже ничем не грозит. Мало того, скажу по секрету, что адаптеру можно дать закрытое соединение. Тогда он его откроет, сделает свое крамольное дело, а потом закроет обратно.

Здравствуйте, Аноним, Вы писали:

А>скажите пожалуйста чем будет отличаться если я закрою коннект а потом перед сохранением открою заново вот так

А>SqlDataAdapter custDA = new SqlDataAdapter("SELECT * FROM Customers", custConn);
А>custDA.Update(ds, myTableName);

Здесь у тебя скорее всего вылетит какой-нибудь эксепшн, ты не указал команд для обновления.
А сконектом не парся SqlDataAdapter сам откроет и закроет коннект если он был закрыт перед вызовом.

А> ну то есть пересоздам dataadapter

Здравствуйте, Аноним, Вы писали:

А>скажите пожалуйста чем будет отличаться если я закрою коннект а потом перед сохранением открою заново вот так

А>SqlDataAdapter custDA = new SqlDataAdapter("SELECT * FROM Customers", custConn);
А>custDA.Update(ds, myTableName);

А> ну то есть пересоздам dataadapter
При работе с датаадаптером (во всяком случае с которыми сталкивался я) нет нужды вручную управлять состоянием соединения — Адаптер все сделает сам.
Соединение открывается только для текущей операции после чего сразу закрывается.

DataSet ds = new DataSet();
custDA.Fill(ds, myTableName);
//изменение данных
custDA.Update(ds, myTableName);
custConn.Close();

скажите пожалуйста чем будет отличаться если я закрою коннект а потом перед сохранением открою заново вот так

SqlDataAdapter custDA = new SqlDataAdapter("SELECT * FROM Customers", custConn);
custDA.Update(ds, myTableName);

ну то есть пересоздам dataadapter

Насколько я по памяти помню, DataAdapter оставляет объект Connection в том состоянии после запроса в котором он был до выполнения запроса, тоесть если объект был открыт то он и останеться открытым, если был закрытым то и останется закрытым.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, DmitryDV, Вы писали:

DDV>Здравствуйте, Аноним, Вы писали:

А>>скажите пожалуйста чем будет отличаться если я закрою коннект а потом перед сохранением открою заново вот так

А>>SqlDataAdapter custDA = new SqlDataAdapter("SELECT * FROM Customers", custConn);
А>>custDA.Update(ds, myTableName);

DDV>Здесь у тебя скорее всего вылетит какой-нибудь эксепшн, ты не указал команд для обновления.
DDV>А сконектом не парся SqlDataAdapter сам откроет и закроет коннект если он был закрыт перед вызовом.

А>> ну то есть пересоздам dataadapter

ну SqlCommandBuilder создан... exceptionOB не должно быть

на remoting сервере валяется типизированный DataSet который соответствует базе данных на sql servere...
так вот клиенты добавляют и изменяют записи в этом датасете, и я не могу понять как лучше и надежнее обновлять sqlserverную БД...

Здравствуйте, Аноним, Вы писали:

А>зы: клиенты добавляют и изменяют записи довольно часто ... я в замешательстве

Я не уверен, что DataSet который соответствует базе данных на sql servere — подходящее решение. Во-первых, это требует памяти и с ростом базы упрешься в outofmemory. Во-вторых, отсоединенный способ работы с базой хорош для клиентов, но не для сервера (DataSet не потокобезопасен).

Я бы предложил клиентам формировать свой DataSet и изменения из него присылать серваку, который их запишет. При такой схеме клиенты не завязаны друг на друга никак.

Здравствуйте, Andrbig, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

А>>зы: клиенты добавляют и изменяют записи довольно часто ... я в замешательстве

A>Я не уверен, что DataSet который соответствует базе данных на sql servere — подходящее решение. Во-первых, это требует памяти и с ростом базы упрешься в outofmemory. Во-вторых, отсоединенный способ работы с базой хорош для клиентов, но не для сервера (DataSet не потокобезопасен).

A>Я бы предложил клиентам формировать свой DataSet и изменения из него присылать серваку, который их запишет. При такой схеме клиенты не завязаны друг на друга никак.


почему это я упрусь в outofmemory? весь датасет заполняться не будет при загрузке сервера, только определенное количество записей, а нужен он для того что бы синхронизировать действия клиентов...

например регистрация заказов: один клиент формирует у себя заказ, посылает его на remoting server, далее мой remoting сервер сохраняет этот заказ и посылает всем ативным клиентам event с данными об этом заказе ну и соответственно складывает данные у себя. новый подключившийся к серверу клиент запрашивает всю текущую таблицу заказов не подключаясь к sql серверу.

Здравствуйте, Аноним, Вы писали:


А>почему это я упрусь в outofmemory? весь датасет заполняться не будет при загрузке сервера, только определенное количество записей, а нужен он для того что бы синхронизировать действия клиентов...

А>например регистрация заказов: один клиент формирует у себя заказ, посылает его на remoting server, далее мой remoting сервер сохраняет этот заказ и посылает всем ативным клиентам event с данными об этом заказе ну и соответственно складывает данные у себя. новый подключившийся к серверу клиент запрашивает всю текущую таблицу заказов не подключаясь к sql серверу.

Так "определенное количество" или "вся таблица"? Это разные вещи. Что до примера, то таблица заказов растет, ибо заказы прибывают. Если "вся таблица", то когда-то память кончится. Если "определенное количество", то новым клиентам все равно придется лезть в базу за всей информацией.

Здравствуйте, Аноним, Вы писали:


А>например регистрация заказов: один клиент формирует у себя заказ, посылает его на remoting server, далее мой remoting сервер сохраняет этот заказ и посылает всем ативным клиентам event с данными об этом заказе ну и соответственно складывает данные у себя

А я бы не стал полагаться на эвенты в ремоутинге, особенно, если от этого будет зависить интегрити данных.

Здравствуйте, Andrbig, Вы писали:

A>Здравствуйте, Аноним, Вы писали:


А>>почему это я упрусь в outofmemory? весь датасет заполняться не будет при загрузке сервера, только определенное количество записей, а нужен он для того что бы синхронизировать действия клиентов...

А>>например регистрация заказов: один клиент формирует у себя заказ, посылает его на remoting server, далее мой remoting сервер сохраняет этот заказ и посылает всем ативным клиентам event с данными об этом заказе ну и соответственно складывает данные у себя. новый подключившийся к серверу клиент запрашивает всю текущую таблицу заказов не подключаясь к sql серверу.

A>Так "определенное количество" или "вся таблица"? Это разные вещи. Что до примера, то таблица заказов растет, ибо заказы прибывают. Если "вся таблица", то когда-то память кончится. Если "определенное количество", то новым клиентам все равно придется лезть в базу за всей информацией.

вся ТЕКУЩАЯ таблица из типизированного датасета...
то есть там (типизированный датасет) храниться не вся таблица заказов а только определенное количество — например 100
и клиент когда подгружается то скачивает всю (состоящую из 100 записей) балицу заказов а н сервере по прежнему их тыщи

Здравствуйте, hugo, Вы писали:

H>Здравствуйте, Аноним, Вы писали:


А>>например регистрация заказов: один клиент формирует у себя заказ, посылает его на remoting server, далее мой remoting сервер сохраняет этот заказ и посылает всем ативным клиентам event с данными об этом заказе ну и соответственно складывает данные у себя

H>А я бы не стал полагаться на эвенты в ремоутинге, особенно, если от этого будет зависить интегрити данных.

откуда такие недоверительные отношения к ивентам?
у меня все проходит нормально с ивентами, настоящая проблема в синхронизации данных с sql serverom

Здравствуйте, Аноним, Вы писали:

А>вся ТЕКУЩАЯ таблица из типизированного датасета...
А>то есть там (типизированный датасет) храниться не вся таблица заказов а только определенное количество — например 100
А>и клиент когда подгружается то скачивает всю (состоящую из 100 записей) балицу заказов а н сервере по прежнему их тыщи

Стоит ли овчинка выделки? Из-за 100 записей столько проблем поиметь... Неужели так часто подключаются клиенты и вытаскивают эти несчастные 100 записей?

Кстати, есть такой Notification Service, может он тебе подойдет, посмотри.

Здравствуйте, Andrbig, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

А>>вся ТЕКУЩАЯ таблица из типизированного датасета...
А>>то есть там (типизированный датасет) храниться не вся таблица заказов а только определенное количество — например 100
А>>и клиент когда подгружается то скачивает всю (состоящую из 100 записей) балицу заказов а н сервере по прежнему их тыщи

A>Стоит ли овчинка выделки? Из-за 100 записей столько проблем поиметь... Неужели так часто подключаются клиенты и вытаскивают эти несчастные 100 записей?


думаю что стоит, хранилище данных может быть не только sql сервер но и другие,
интерфейс к remoting серверу унифицирован...


A>Кстати, есть такой Notification Service, может он тебе подойдет, посмотри.

а что за зверь такой?

Здравствуйте, Аноним, Вы писали:

A>>Стоит ли овчинка выделки? Из-за 100 записей столько проблем поиметь... Неужели так часто подключаются клиенты и вытаскивают эти несчастные 100 записей?

А>думаю что стоит, хранилище данных может быть не только sql сервер но и другие,
А>интерфейс к remoting серверу унифицирован...

Какое отношение унификация интерфейсов имеет к частоте подключения клиентов? Если клиенты подключаются нечасто, то пусть вытаскивают все по своему унифицированному интерфейсу ради бога.

A>>Кстати, есть такой Notification Service, может он тебе подойдет, посмотри.

А>а что за зверь такой?

Следит за изменениями в ms sql базе и бросает сообщениями при внесении туда изменений.

Здравствуйте, Andrbig, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

A>>>Стоит ли овчинка выделки? Из-за 100 записей столько проблем поиметь... Неужели так часто подключаются клиенты и вытаскивают эти несчастные 100 записей?

А>>думаю что стоит, хранилище данных может быть не только sql сервер но и другие,
А>>интерфейс к remoting серверу унифицирован...

A>Какое отношение унификация интерфейсов имеет к частоте подключения клиентов? Если клиенты подключаются нечасто, то пусть вытаскивают все по своему унифицированному интерфейсу ради бога.

я так понял про овчинку относится к типизированому датасету...
вот я и сказал что данные считываться с хранилища и сохраняться туда могут поразному а клиент получует строго определенные данные для этих целей и заполняется типизированный датасет

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Andrbig, Вы писали:

A>>Здравствуйте, Аноним, Вы писали:

A>>>>Стоит ли овчинка выделки? Из-за 100 записей столько проблем поиметь... Неужели так часто подключаются клиенты и вытаскивают эти несчастные 100 записей?

А>>>думаю что стоит, хранилище данных может быть не только sql сервер но и другие,
А>>>интерфейс к remoting серверу унифицирован...

A>>Какое отношение унификация интерфейсов имеет к частоте подключения клиентов? Если клиенты подключаются нечасто, то пусть вытаскивают все по своему унифицированному интерфейсу ради бога.

А>я так понял про овчинку относится к типизированому датасету...
А>вот я и сказал что данные считываться с хранилища и сохраняться туда могут поразному а клиент получует строго определенные данные для этих целей и заполняется типизированный датасет

То что данные могут по разному считываться и сохраняться — здорово, но к вопросу отношения не имеет. Вопрос — зачем хранить данные на сервере приложений? Клиент стартовал — запрос на сервер приложений — тот выполнил запрос на базу — получил 100 записей — сунул их в типизированный датасет — отдал клиенту.

A>То что данные могут по разному считываться и сохраняться — здорово, но к вопросу отношения не имеет. Вопрос — зачем хранить данные на сервере приложений? Клиент стартовал — запрос на сервер приложений — тот выполнил запрос на базу — получил 100 записей — сунул их в типизированный датасет — отдал клиенту.

отдал клиенту и очистил датасет?

а если клиент сохраняет новую запись с автоинкрементным полем тогда как быть?
использовать свое значение локальное автоинкремента он не может
на моем серверной части датасет пуст а сохранять сразу в sql serverenую бд надо прописывать insert команду для каждой таблицы...

Здравствуйте, Аноним, Вы писали:

A>>То что данные могут по разному считываться и сохраняться — здорово, но к вопросу отношения не имеет. Вопрос — зачем хранить данные на сервере приложений? Клиент стартовал — запрос на сервер приложений — тот выполнил запрос на базу — получил 100 записей — сунул их в типизированный датасет — отдал клиенту.

А>отдал клиенту и очистил датасет?

Да. Просто не храни ссылки на датасет и мусорщик его уберет.

А>а если клиент сохраняет новую запись с автоинкрементным полем тогда как быть?
А>использовать свое значение локальное автоинкремента он не может
А>на моем серверной части датасет пуст а сохранять сразу в sql serverenую бд надо прописывать insert команду для каждой таблицы...

Не очень понял в чем именно проблема. Записывается новая запись, есть автоинкремент — это понятно. Что непонятно? Как получить значение вставленной записи? Использовать ли автоинкремент или генерить самому? Как получить какие ID соответствуют при нескольких строками на запись?