Здравствуйте IT, Вы писали:
IT>Здравствуйте Гром Олег Васильевич, Вы писали:
ГОВ>>Такой вопрос работает ли кто с старым добрым ADO на VS.NET?
IT>А какой смысл? Новое ADO после адаптационного периода смотрится вполне прилично.
Но не для всех задач.
1. ADO.NET не поддерживает серверные курсоры.
2. Невозможно произвольное перемещение по таблицам без загрузки в датасет.
3. Для обновления данніх нужно перезаполнять датасет и тд.
ГОВ>>И если да то какие для этой цели использовать контролы?.
IT>Те же самые, только придётся всё самому перекачивать в DataSet.
А смысл тогда использовать ADO если все одно нужно грузить таблицу в память.
Естественно работать нужно работать с ADO рекордсетом.
Здравствуйте Гром Олег Васильевич, Вы писали:
ГОВ>Такой вопрос работает ли кто с старым добрым ADO на VS.NET?
Работал.
ГОВ>И если да то какие для этой цели использовать контролы?.
Свои собственные.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Гром Олег Васильевич, Вы писали:
ГОВ>>Такой вопрос работает ли кто с старым добрым ADO на VS.NET? AVK>Работал.
ГОВ>>И если да то какие для этой цели использовать контролы?. AVK>Свои собственные.
Не могли бы вы выслать примерчик програмки с ADO.
Зарание благодарен.
Самая большая проблема возникает при использовании Грида
его что тоже самому писать???
Здравствуйте Thunder, Вы писали:
ГОВ>>>И если да то какие для этой цели использовать контролы?. AVK>>Свои собственные. T>Не могли бы вы выслать примерчик програмки с ADO.
Выслать можно, но там пример совсем не показательный, GUI там вобще нет. Можешь посмотреть на xobjects.narod.ru
T>Самая большая проблема возникает при использовании Грида T>его что тоже самому писать???
Да, Или искать ActiveX.
Здравствуйте IT, Вы писали:
IT>Здравствуйте Гром Олег Васильевич, Вы писали:
ГОВ>>Такой вопрос работает ли кто с старым добрым ADO на VS.NET?
IT>А какой смысл? Новое ADO после адаптационного периода смотрится вполне прилично.
А если на сервере приложений .NET, а на клинетах нет? И только, старое доброе ADO?
ГОВ>>И если да то какие для этой цели использовать контролы?.
IT>Те же самые, только придётся всё самому перекачивать в DataSet.
А зачем в ручную перекачивать, когда есть Ole DB .NET Data Provider?
In the .NET Framework, you can access existing components that return ADO Recordset or Record objects, and you can also access ADO Recordset and Record objects directly using the OLE DB .NET Data Provider. The OLE DB .NET Data Provider supports filling a DataSet from an ADO Recordset or Record. This enables you to consume existing Component Object Model (COM) objects that return ADO objects, without having to rewrite them entirely using the .NET Framework.
Здравствуйте kig, Вы писали:
kig>Здравствуйте IT, Вы писали:
IT>>Здравствуйте Гром Олег Васильевич, Вы писали:
ГОВ>>>Такой вопрос работает ли кто с старым добрым ADO на VS.NET?
IT>>А какой смысл? Новое ADO после адаптационного периода смотрится вполне прилично.
kig>А если на сервере приложений .NET, а на клинетах нет? И только, старое доброе ADO?
Не совсем понял ваш ответ. Если можно поясните.
ГОВ>>>И если да то какие для этой цели использовать контролы?.
IT>>Те же самые, только придётся всё самому перекачивать в DataSet.
kig>А зачем в ручную перекачивать, когда есть Ole DB .NET Data Provider?
kig>In the .NET Framework, you can access existing components that return ADO Recordset or Record objects, and you can also access ADO Recordset and Record objects directly using the OLE DB .NET Data Provider. The OLE DB .NET Data Provider supports filling a DataSet from an ADO Recordset or Record. This enables you to consume existing Component Object Model (COM) objects that return ADO objects, without having to rewrite them entirely using the .NET Framework.
Но при єтом придется зхакачивать всю таблицу — а если она большая?
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Thunder, Вы писали:
ГОВ>>>>И если да то какие для этой цели использовать контролы?. AVK>>>Свои собственные. T>>Не могли бы вы выслать примерчик програмки с ADO. AVK>Выслать можно, но там пример совсем не показательный, GUI там вобще нет. Можешь посмотреть на xobjects.narod.ru
T>>Самая большая проблема возникает при использовании Грида T>>его что тоже самому писать??? AVK>Да, Или искать ActiveX.
Я уже перепробовал кучу гридов но все они коряво работают под VS.NET
Нет ли у тебя подходящего хотябы только для просмотра.
А с 0 писать не сильно хочится да и времени уйдет много.
Здравствуйте kig, Вы писали:
IT>>А какой смысл? Новое ADO после адаптационного периода смотрится вполне прилично.
kig>А если на сервере приложений .NET, а на клинетах нет? И только, старое доброе ADO?
Если есть сервер приложений, то зачем ADO на клиенте?
Здравствуйте Thunder, Вы писали:
T>Нет ли у тебя подходящего хотябы только для просмотра.
Для просмотра в качестве грида вполне покатит WeBrowser control
T>А с 0 писать не сильно хочится да и времени уйдет много.
Я думаю не стоит извращаться и для БД гуя лучше пользовать ADO.NET, ибо в этом случае все равно выборки придется целиком в память забирать, пусть это и делается неявно.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Thunder, Вы писали:
T>>Нет ли у тебя подходящего хотябы только для просмотра. AVK>Для просмотра в качестве грида вполне покатит WeBrowser control
T>>А с 0 писать не сильно хочится да и времени уйдет много. AVK>Я думаю не стоит извращаться и для БД гуя лучше пользовать ADO.NET, ибо в этом случае все равно выборки придется целиком в память забирать, пусть это и делается неявно.
А как реализовать в .NET быстрый поиск — пользователь вводит с клавиатуры первые символы а курсор автоматически находит нужную запись. Для этого нужно грузить всю таблицу в память но есть несколько проблем
1. Если таблица большая то это занимает много времени.
2. Если таблица загружена в памяти, а другой пользователь уже внес в нее изменения придется перегрузить таблицу в датасет.
3. А если таких таблиц для поиска не одна а много на одной форме?
Я всеже думаю что ADO.NET это неплохое развитее ADO но оно неспособно во всех случаях замениьть ADO. И к томуже в самой VS.NET Server Explorer использует ADO.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
IT>>>А какой смысл? Новое ADO после адаптационного периода смотрится вполне прилично.
kig>>А если на сервере приложений .NET, а на клинетах нет? И только, старое доброе ADO?
AVK>Если есть сервер приложений, то зачем ADO на клиенте?
Предпосылок множество, но все они упираются примерно в следующее:
1. Отсутствие дотнет на клиенте.
2. По условиям задачи нет возможности использовать чистого browser-клиента (попробуйте бухгалтера или девочку, которая вводит накладные, затавить работать на browser-клиенте).
3. Приложения клиента(ов) уже есть, необходимо наименьшими затратами, с одной стороны, сервер приложений перевести на новые технологии, с другой стороны не переписывать (или минимизировать) клиента(ов).
Здравствуйте Thunder, Вы писали:
IT>>>А какой смысл? Новое ADO после адаптационного периода смотрится вполне прилично.
kig>>А если на сервере приложений .NET, а на клинетах нет? И только, старое доброе ADO?
T>Не совсем понял ваш ответ. Если можно поясните.
Вообще-то я вдогонку привел еще один довод, наряду с Вашими.
" T>Но не для всех задач. T>1. ADO.NET не поддерживает серверные курсоры. T>2. Невозможно произвольное перемещение по таблицам без загрузки в датасет.
"
Здесь ниже по ветке я AndrewVK ответил более подробно...
ГОВ>>>>И если да то какие для этой цели использовать контролы?.
IT>>>Те же самые, только придётся всё самому перекачивать в DataSet.
kig>>А зачем в ручную перекачивать, когда есть Ole DB .NET Data Provider?
kig>>In the .NET Framework, you can access existing components that return ADO Recordset or Record objects, and you can also access ADO Recordset and Record objects directly using the OLE DB .NET Data Provider. The OLE DB .NET Data Provider supports filling a DataSet from an ADO Recordset or Record. This enables you to consume existing Component Object Model (COM) objects that return ADO objects, without having to rewrite them entirely using the .NET Framework.
T>Но при єтом придется зхакачивать всю таблицу — а если она большая?
Ну это конечно да... просто в ручную перекачивать не надо — вернее в дотнете это уже реализовано.
Здравствуйте Thunder, Вы писали:
T>Здравствуйте AndrewVK, Вы писали:
AVK>>Здравствуйте Thunder, Вы писали:
T>>>Нет ли у тебя подходящего хотябы только для просмотра. AVK>>Для просмотра в качестве грида вполне покатит WeBrowser control
T>>>А с 0 писать не сильно хочится да и времени уйдет много. AVK>>Я думаю не стоит извращаться и для БД гуя лучше пользовать ADO.NET, ибо в этом случае все равно выборки придется целиком в память забирать, пусть это и делается неявно.
T>А как реализовать в .NET быстрый поиск — пользователь вводит с клавиатуры первые символы а курсор автоматически находит нужную запись. Для этого нужно грузить всю таблицу в память но есть несколько проблем T>1. Если таблица большая то это занимает много времени.
А зачем загружать сразу всю таблицу? Это можно желать и порциями T>2. Если таблица загружена в памяти, а другой пользователь уже внес в нее изменения придется перегрузить таблицу в датасет.
Обычно пользователь меняет не всю таблицу, а одну запись... Тут замечательно поможет DataSet.Merge
А как поможет ADO в случае использования клиентских курсоров?
T>3. А если таких таблиц для поиска не одна а много на одной форме?
А в ADO работа со множеством таблиц сделана просто замечательно Особенно с Identity полями... Особенно когда помимо основоной записи нужно вставить еще десяток подчиненных...
T>Я всеже думаю что ADO.NET это неплохое развитее ADO но оно неспособно во всех случаях замениьть ADO. И к томуже в самой VS.NET Server Explorer использует ADO.
А почему не System.Data.OleDb? Да и потом для использования Ole Db есть свои причины...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте Thunder, Вы писали:
T>А как реализовать в .NET быстрый поиск — пользователь вводит с клавиатуры первые символы а курсор автоматически находит нужную запись. Для этого нужно грузить всю таблицу в память но есть несколько проблем T>1. Если таблица большая то это занимает много времени.
Да T>2. Если таблица загружена в памяти, а другой пользователь уже внес в нее изменения придется перегрузить таблицу в датасет.
Да
В общем то ты прав, поэтому просто стоит избегать подобного построения интерфейса. Практика показывает что это возможно почти всегда.
Ну а если очень хочется то:
1) стараться ограничивать таблицу условиями.
2) преобразовать таблицу в иерархический вид
3) при наборе реагировать с небольшой задержкой — уменьшит количество выборок.
T>Я всеже думаю что ADO.NET это неплохое развитее ADO но оно неспособно во всех случаях замениьть ADO.
Да T> И к томуже в самой VS.NET Server Explorer использует ADO.
ADOX
Здравствуйте kig, Вы писали:
IT>>>>А какой смысл? Новое ADO после адаптационного периода смотрится вполне прилично.
kig>>>А если на сервере приложений .NET, а на клинетах нет? И только, старое доброе ADO?
AVK>>Если есть сервер приложений, то зачем ADO на клиенте?
kig>Предпосылок множество, но все они упираются примерно в следующее:
kig>1. Отсутствие дотнет на клиенте.
зачем тогда сервер приложений? И как ты его собираешся без дотнета пользовать?
kig>2. По условиям задачи нет возможности использовать чистого browser-клиента (попробуйте бухгалтера или девочку, которая вводит накладные, затавить работать на browser-клиенте).
Это понятно
kig>3. Приложения клиента(ов) уже есть, необходимо наименьшими затратами, с одной стороны, сервер приложений перевести на новые технологии, с другой стороны не переписывать (или минимизировать) клиента(ов).
kig>Конечно, все это трудности переходного периода...
Я боюсь что совместить прямой доступ данных и сервер приложений совместить не получится. Из-за необходимости синхронизации нельзя будет кешировать данные, а при этом весь смысл использования серверов приложений отпадает.
Здравствуйте Thunder, Вы писали:
T>Я всеже думаю что ADO.NET это неплохое развитее ADO но оно неспособно во всех случаях замениьть ADO. И к томуже в самой VS.NET Server Explorer использует ADO.
ADO.NET вполне нормально вписывается в обновлённую идеологию MS распределённых систем (это моё ИМХО, конечно), которая всё больше ориентируется на stateless системы, как на наиболее надёжные, масштабируемые и менее ресурсоёмкие, и уходит от stateful, у которых есть только одно преимущество — быстродейсвие, которое в свою очередь также быстро заканчивается при увеличении нагрузки на систему.
ADO.NET не предполагает открытие соединения с базой данных на долгое время. Надо придерживаться следующей схемы — открыл базу, быстренько взял данные или произвёл изменения, закрыл базу.
Как я понимаю, ты хочешь открыть соединение с базой, понаоткрывать server-side рекорсетов и по мере надобности искать в них данные. Это будет работать до тех пор, пока у тебя в сети 10 пользователей. А если их 1000 и программа каждого постоянно держит не одно соединение, а несколько, да ещё по 10 рекорсетов на каждом? Любой SQL сервер офигеет от этого очень быстро.
Хотя конечно если ты не предполагаешь большого количества пользователей, то ADO.NET здесь будет в проигрыше перед ADO.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>ADO.NET вполне нормально вписывается в обновлённую идеологию MS распределённых систем (это моё ИМХО, конечно), которая всё больше ориентируется на stateless системы, как на наиболее надёжные, масштабируемые и менее ресурсоёмкие, и уходит от stateful, у которых есть только одно преимущество — быстродейсвие, которое в свою очередь также быстро заканчивается при увеличении нагрузки на систему.
Но иногда без этого простоне не обойтись.
IT>ADO.NET не предполагает открытие соединения с базой данных на долгое время. Надо придерживаться следующей схемы — открыл базу, быстренько взял данные или произвёл изменения, закрыл базу.
Это я знаю но в локальной сети 100 Mb или выше я думаю это вполне допустимо.
IT>Как я понимаю, ты хочешь открыть соединение с базой, понаоткрывать server-side рекорсетов и по мере надобности искать в них данные. Это будет работать до тех пор, пока у тебя в сети 10 пользователей. А если их 1000 и программа каждого постоянно держит не одно соединение, а несколько, да ещё по 10 рекорсетов на каждом? Любой SQL сервер офигеет от этого очень быстро.
Ну не скажи зачем же так все усугублять открывать рекордсеты только в режиме редактирования. И я думаю при 1000 пользователях максимум человек 100 может одновременно изменять данные (на практике их гораздо меньше) в основном идет просмотр данных. А в моей системе их всего будет не больше 100.
IT>Хотя конечно если ты не предполагаешь большого количества пользователей, то ADO.NET здесь будет в проигрыше перед ADO.
Я собственно почему поднял этот вопрос в VS.NET есть библиотека ADO 2.7 но котролов для ее использования нет.
Может кто работал с этой библиотекой и если да то какие контролы он использовал.
Здравствуйте IT, Вы писали:
IT>ADO.NET вполне нормально вписывается в обновлённую идеологию MS распределённых систем (это моё ИМХО, конечно), которая всё больше ориентируется на stateless системы, как на наиболее надёжные, масштабируемые и менее ресурсоёмкие, и уходит от stateful, у которых есть только одно преимущество — быстродейсвие, которое в свою очередь также быстро заканчивается при увеличении нагрузки на систему.
Все это правильно, но многие вещи не реализуемы stateless в принципе. Тут несколько другой уклон — state нужно выносить в апп сервер. А вот с sql сервером stateful общение совсем не обязательно.
Если нам не помогут, то мы тоже никого не пощадим.
Особенно с Identity полями... Особенно когда помимо основоной записи нужно вставить еще десяток подчиненных...