Здравствуйте 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 общение совсем не обязательно.
Здравствуйте Thunder, Вы писали:
IT>>Как я понимаю, ты хочешь открыть соединение с базой, понаоткрывать server-side рекорсетов и по мере надобности искать в них данные. Это будет работать до тех пор, пока у тебя в сети 10 пользователей. А если их 1000 и программа каждого постоянно держит не одно соединение, а несколько, да ещё по 10 рекорсетов на каждом? Любой SQL сервер офигеет от этого очень быстро.
T>Ну не скажи зачем же так все усугублять открывать рекордсеты только в режиме редактирования. И я думаю при 1000 пользователях максимум человек 100 может одновременно изменять данные (на практике их гораздо меньше) в основном идет просмотр данных. А в моей системе их всего будет не больше 100.
Понимаешь в чем дело — выборки все равно будут храниться на сервере в памяти. Выигрыш серверных курсоров может быть только в кешировании. А задача кеширования решается сервером приложений на порядок эффективнее. Ну а если курсоры клиентские то все равно даже с ADO вся выборка будет сбрасываться разом и перегружаться при каждом рефреше. Если вспомнить что серверные курсоры появились относительно недавно то я не думаю что при работе с sql-сервером мы получим что то сильно отличное в плане быстродействия от того что было. Просто если раньше процесс получения выборок был автоматическим то в ADO.NET этот процесс можно контролировать.
T>Я собственно почему поднял этот вопрос в VS.NET есть библиотека ADO 2.7 но котролов для ее использования нет.
ADO идет сама по себе. До недавнего времени это была основная библиотека доступа к данным от MS.
T>Может кто работал с этой библиотекой и если да то какие контролы он использовал.
Это зависит от средства разработки. В Дельфи например с ADO работают ее стандартные контролы.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
IT>>>>>А какой смысл? Новое ADO после адаптационного периода смотрится вполне прилично.
kig>>>>А если на сервере приложений .NET, а на клинетах нет? И только, старое доброе ADO?
AVK>>>Если есть сервер приложений, то зачем ADO на клиенте?
kig>>Предпосылок множество, но все они упираются примерно в следующее:
kig>>1. Отсутствие дотнет на клиенте. AVK>зачем тогда сервер приложений? И как ты его собираешся без дотнета пользовать?
Последнюю фразу двояко можно понять... То ли сервер без дотнета, то ли клиент.
kig>>2. По условиям задачи нет возможности использовать чистого browser-клиента (попробуйте бухгалтера или девочку, которая вводит накладные, затавить работать на browser-клиенте). AVK>Это понятно
kig>>3. Приложения клиента(ов) уже есть, необходимо наименьшими затратами, с одной стороны, сервер приложений перевести на новые технологии, с другой стороны не переписывать (или минимизировать) клиента(ов).
kig>>Конечно, все это трудности переходного периода... AVK>Я боюсь что совместить прямой доступ данных и сервер приложений совместить не получится. Из-за необходимости синхронизации нельзя будет кешировать данные, а при этом весь смысл использования серверов приложений отпадает.
Не идет разговор о прямом доступе. Я же не из головы все это выдумываю. Вот конкретика — есть система, стоящая, так, примерно, у 100 заказчиков. Система построена на многозвенке. В качестве клиента выступает приложение на Д, но общается этот клиент не БД, а с сервером приложений (СП).
И вот появился дотнет. Казалось бы, давайте все перенесем под него. Но проблема в том, что заказчики не пойдут на финансирование полной переделки все системы, и клиентов, и СП. А развивать СП хотелось бы уже в новой технологии. Напрашивается след. решения:
1. Плюнуть на все и оставить все как есть....
2. Параллельно развивать две системы и новым заказчикам представлять уже на новой технологии — это накладно — придется еще и поддерживать 2 системы (и клиентов и СП).
3. Пока, пока идет переходный период с ... на дотнет, в том числе и на клиентах... переписать пока только СП, а клиента только адаптировать на новый стык с СП. И более клиента не трогать. Тем более, что основной процесс переваривания (бизнес-логика) все равно крутиться на СП. И изменения в системе (развитие) ложаться на 95% имено на изменения в СП.
Здравствуйте kig, Вы писали:
kig>1. Плюнуть на все и оставить все как есть.... kig>2. Параллельно развивать две системы и новым заказчикам представлять уже на новой технологии — это накладно — придется еще и поддерживать 2 системы (и клиентов и СП). kig>3. Пока, пока идет переходный период с ... на дотнет, в том числе и на клиентах... переписать пока только СП, а клиента только адаптировать на новый стык с СП. И более клиента не трогать. Тем более, что основной процесс переваривания (бизнес-логика) все равно крутиться на СП. И изменения в системе (развитие) ложаться на 95% имено на изменения в СП.
Ну все правильно в общем то, но при чем здесь ADO на клиенте?
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
kig>>1. Плюнуть на все и оставить все как есть.... kig>>2. Параллельно развивать две системы и новым заказчикам представлять уже на новой технологии — это накладно — придется еще и поддерживать 2 системы (и клиентов и СП). kig>>3. Пока, пока идет переходный период с ... на дотнет, в том числе и на клиентах... переписать пока только СП, а клиента только адаптировать на новый стык с СП. И более клиента не трогать. Тем более, что основной процесс переваривания (бизнес-логика) все равно крутиться на СП. И изменения в системе (развитие) ложаться на 95% имено на изменения в СП.
AVK>Ну все правильно в общем то, но при чем здесь ADO на клиенте?
Да просто из-за удобства.
Полно приблуд, контролов, особенно в Д, уже заточенных для работы и отображения регулярных структур даннных. Плюс корреляция с НД в сервере БД. На клиента через ADO-поток данные, оттуда — выжимка изменений — обработка на СП бизнес-логикой этих изменений... ну т.д. и т.п.
В принципе, только для этого.
Здравствуйте kig, Вы писали:
kig>Да просто из-за удобства. kig>Полно приблуд, контролов, особенно в Д, уже заточенных для работы и отображения регулярных структур даннных. Плюс корреляция с НД в сервере БД. На клиента через ADO-поток данные, оттуда — выжимка изменений — обработка на СП бизнес-логикой этих изменений... ну т.д. и т.п. kig>В принципе, только для этого.
Т.е. в соотв. с идеологией Дельфей апп сервер работает не с объектами а с рекордсетами? И доступ к данным осуществляется через своего ADO провайдера? Думаю вам все же надо переходить на объектную модель, иначе всех прелестей дотнета вы не поимеете.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
kig>>Да просто из-за удобства. kig>>Полно приблуд, контролов, особенно в Д, уже заточенных для работы и отображения регулярных структур даннных. Плюс корреляция с НД в сервере БД. На клиента через ADO-поток данные, оттуда — выжимка изменений — обработка на СП бизнес-логикой этих изменений... ну т.д. и т.п. kig>>В принципе, только для этого. AVK>Т.е. в соотв. с идеологией Дельфей апп сервер работает не с объектами а с рекордсетами? И доступ к данным осуществляется через своего ADO провайдера? Думаю вам все же надо переходить на объектную модель, иначе всех прелестей дотнета вы не поимеете.
Сервер работает не с рекордсетами как таковыми, а представляет их ... ну как бы сериализованные данные определенных объетов. По аналогии с дотнетом можно представить себе класс, который рожается от датасета + своя бизнес логика. Ну а сейчас — бизнес-объект, как бы надстройка над ADO-рекордсетом
А для такой, как бы сказать, сериализации, на данном этапе используются адошные возможности. Ну это, конечно в идеале... В некоторых местах идет работа напрямую с рекордсетами ... Ну так уж исторически сложилось. И щас это если и будем переделывать, то только на дотнете.
Свой провайдер мы не используем... нам он не нужен
В будущем, при переходе на дотнет, это то же еще под вопросом останется — гонять между клиентом и сервером свои сериализованные "чистые" объекты, или рожать их уже от датасета.
Здравствуйте kig, Вы писали:
kig>Сервер работает не с рекордсетами как таковыми, а представляет их ... ну как бы сериализованные данные определенных объетов. По аналогии с дотнетом можно представить себе класс, который рожается от датасета + своя бизнес логика. Ну а сейчас — бизнес-объект, как бы надстройка над ADO-рекордсетом
kig>А для такой, как бы сказать, сериализации, на данном этапе используются адошные возможности. Ну это, конечно в идеале... В некоторых местах идет работа напрямую с рекордсетами ... Ну так уж исторически сложилось. И щас это если и будем переделывать, то только на дотнете.
kig>Свой провайдер мы не используем... нам он не нужен
То есть как это? Какого провайдера надо указывать ADO на клиенте?
kig>В будущем, при переходе на дотнет, это то же еще под вопросом останется — гонять между клиентом и сервером свои сериализованные "чистые" объекты, или рожать их уже от датасета.
Я думаю надо это делать сразу а не откладывать на потом.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
kig>>Сервер работает не с рекордсетами как таковыми, а представляет их ... ну как бы сериализованные данные определенных объетов. По аналогии с дотнетом можно представить себе класс, который рожается от датасета + своя бизнес логика. Ну а сейчас — бизнес-объект, как бы надстройка над ADO-рекордсетом
kig>>А для такой, как бы сказать, сериализации, на данном этапе используются адошные возможности. Ну это, конечно в идеале... В некоторых местах идет работа напрямую с рекордсетами ... Ну так уж исторически сложилось. И щас это если и будем переделывать, то только на дотнете.
kig>>Свой провайдер мы не используем... нам он не нужен
AVK>То есть как это? Какого провайдера надо указывать ADO на клиенте?
Из предыдущего поста
"... И доступ к данным осуществляется через своего ADO провайдера? ... " я это воспринял как собственный OLEDB-провайдер.
Конечно на сервере используется провайдер SQL. На клиенте никаких провайдеров не указывается.
kig>>В будущем, при переходе на дотнет, это то же еще под вопросом останется — гонять между клиентом и сервером свои сериализованные "чистые" объекты, или рожать их уже от датасета. AVK>Я думаю надо это делать сразу а не откладывать на потом.
Здравствуйте kig, Вы писали:
kig>Из предыдущего поста kig>"... И доступ к данным осуществляется через своего ADO провайдера? ... " я это воспринял как собственный OLEDB-провайдер.
Ну правильно ты воспринял
kig>Конечно на сервере используется провайдер SQL. На клиенте никаких провайдеров не указывается.
Нифига опять не понимаю. Как клиент взаимодействует с сервером приложений?
kig>Решить вопрос?
Перейти на объектное представление. А проблему старых клиентов решить написанием собственного IRemotingFormatter. После этого вешаешь стандартного провайдера на один порт, самописного на другой и имеешь доступ и для старых клиентов и для новых.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
kig>>Из предыдущего поста kig>>"... И доступ к данным осуществляется через своего ADO провайдера? ... " я это воспринял как собственный OLEDB-провайдер. AVK>Ну правильно ты воспринял
А зачем, когда нам щас вполне хватает sql-ного.
kig>>Конечно на сервере используется провайдер SQL. На клиенте никаких провайдеров не указывается. AVK>Нифига опять не понимаю. Как клиент взаимодействует с сервером приложений?
По TCP/IP.
Чего-то я теперь Вас понять не могу. Я же сказал — многозвенка. Клиент вообще не знает, что такое БД и где она и на чем она... и т.д. Клиент общается с аппсервером — вот его он знает. И причем здесь провайдер, который OLEDB?
Или Вы себе представили, что в качестве аппсервера выступает OLEDB-провайдер?
kig>>Решить вопрос? AVK>Перейти на объектное представление. А проблему старых клиентов решить написанием собственного IRemotingFormatter. После этого вешаешь стандартного провайдера на один порт, самописного на другой и имеешь доступ и для старых клиентов и для новых.
Ну это решение, если клиенты будут и новые и старые. Одновременно.
Но я же сказал, не будем мы пока клиентов трогать... будут они старые. Вот для того, что бы форматеры не писать — как гоняли они стримы адощные — так и будут. Ну можно представить, что адошный стрим — частный случай такого форматера.
А по поводу объектного представления — ну на серваке так и есть (почти везде). Или разговор пошел о объктах на клиенте?
Здравствуйте kig, Вы писали:
kig>А зачем, когда нам щас вполне хватает sql-ного.
Т.е. вы эмулируете MSSQL?
kig>По TCP/IP. kig>Чего-то я теперь Вас понять не могу. Я же сказал — многозвенка. Клиент вообще не знает, что такое БД и где она и на чем она... и т.д. Клиент общается с аппсервером — вот его он знает. И причем здесь провайдер, который OLEDB?
Т.е. используется свой собственный протокол? Тогда еще раз — при чем здесь ADO? Трехзвенка это не магическое слово которое все объясняет.
kig>Или Вы себе представили, что в качестве аппсервера выступает OLEDB-провайдер?
Я себе представляю что для доступа к апп серверу используется OLEDB-провайдер. Иного использования ADO в трехзвенных приложениях я не вижу.
AVK>>Перейти на объектное представление. А проблему старых клиентов решить написанием собственного IRemotingFormatter. После этого вешаешь стандартного провайдера на один порт, самописного на другой и имеешь доступ и для старых клиентов и для новых.
kig>Ну это решение, если клиенты будут и новые и старые. Одновременно. kig>Но я же сказал, не будем мы пока клиентов трогать... будут они старые. Вот для того, что бы форматеры не писать — как гоняли они стримы адощные — так и будут.
Что понимается под "гонянием адошных стримов"? Выдергивание готовых рекордсетов по DCOM?
kig> Ну можно представить, что адошный стрим — частный случай такого форматера.
Какой то у вас очень странный сервер приложений. Мне все больше кажется что нужно похерить и переписать по новой — в итоге будет быстрее.
kig>А по поводу объектного представления — ну на серваке так и есть (почти везде). Или разговор пошел о объктах на клиенте?
Прежде всего на сервере. А на клиенте по желанию. Лучше конечно тоже.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
kig>>А зачем, когда нам щас вполне хватает sql-ного. AVK>Т.е. вы эмулируете MSSQL?
Зачем???? и где??? о чем речь то идет?
kig>>По TCP/IP. kig>>Чего-то я теперь Вас понять не могу. Я же сказал — многозвенка. Клиент вообще не знает, что такое БД и где она и на чем она... и т.д. Клиент общается с аппсервером — вот его он знает. И причем здесь провайдер, который OLEDB? :???: AVK>Т.е. используется свой собственный протокол? Тогда еще раз — при чем здесь ADO? Трехзвенка это не магическое слово которое все объясняет.
Используется протокол тот, который в Борланде. Borland Socket Server.
А адо здесь при одном — мне чего, гриды собственные писать, что бы отображать списки или коллекции в морде клиента? Или еще какие контролы. Оно мне надо? Когда полно db-аварных компонентов, которым начхать, откуда набор данных появился. Из БД скачан, с аппсервера приехал или вообще в памяти создан?
Вот для чего используется ado, в звязке (производное от TАдоDataset) — TDataSource — TDBGrid.. TDBCombj и т.п.
С таким же успехом мы могли бы использовать просто борландовский TClientDataset, но что-то нам подсказало, что не далеко те времена, которые щас наступили. А в дотнете с TClientDataset наверно еще и повозиться придется, и результат этого заранее неопределен.
kig>>Или Вы себе представили, что в качестве аппсервера выступает OLEDB-провайдер? AVK>Я себе представляю что для доступа к апп серверу используется OLEDB-провайдер. Иного использования ADO в трехзвенных приложениях я не вижу.
Это почему не видишь? Только тем, что данные, типа, через провайдер поставляются? А чем отличие, ну например, RDS (remote provider), кроме того, что он провайдером называется, от Borland Socket Server? Наборы данных он чего, святым духом пересылает? Точно так же рекодсеты в виде потоков гонит, или по DCOM, или по HTTP. А вот tcp/ip стыка у него нет, поэтому и не подошел нам.
Тем более, что Борланд уже представляет, пускай другой, но работающтй способ. И мне им не пользоваться, только потому что он выполнен не в виде оledb-провайдера?
Да и по сути — делают они одно и тоже, пока разговор о даныых идет. А вот только возможностей у Борланда перед RDS поболее. Например дернуть объет за метод на серваке RDS не может (на то он и провайдер).
AVK>>>Перейти на объектное представление. А проблему старых клиентов решить написанием собственного IRemotingFormatter. После этого вешаешь стандартного провайдера на один порт, самописного на другой и имеешь доступ и для старых клиентов и для новых.
kig>>Ну это решение, если клиенты будут и новые и старые. Одновременно. kig>>Но я же сказал, не будем мы пока клиентов трогать... будут они старые. Вот для того, что бы форматеры не писать — как гоняли они стримы адощные — так и будут. AVK>Что понимается под "гонянием адошных стримов"? Выдергивание готовых рекордсетов по DCOM?
по tcp/ip
kig>> Ну можно представить, что адошный стрим — частный случай такого форматера. AVK>Какой то у вас очень странный сервер приложений. Мне все больше кажется что нужно похерить и переписать по новой — в итоге будет быстрее.
см. выше да и зачем переписывать, когда работает. И быстро и устойчиво.
kig>>А по поводу объектного представления — ну на серваке так и есть (почти везде). Или разговор пошел о объктах на клиенте? AVK>Прежде всего на сервере. А на клиенте по желанию. Лучше конечно тоже.
Да я уже говорил, что на серваке — это объкты. Дернул метод на апп — получил набор (например). Дернул другой метод на апп — отдал изменения, сделанные в нем. А чего он там с ними делает, клиенту по барабану. Сохраняет куда, делает при этом массовые изменения, связанные с логикой... клиент об этом не задумывается.
Здравствуйте kig, Вы писали:
AVK>>Т.е. используется свой собственный протокол? Тогда еще раз — при чем здесь ADO? Трехзвенка это не магическое слово которое все объясняет. kig>Используется протокол тот, который в Борланде. Borland Socket Server.
Дальше давай. Ну что приходится из тебя вытягивать подробности клещами. Если тебе известно как работает твой софт это совсем не значит что это известно другим.
kig>А адо здесь при одном — мне чего, гриды собственные писать, что бы отображать списки или коллекции в морде клиента? Или еще какие контролы. Оно мне надо? Когда полно db-аварных компонентов, которым начхать, откуда набор данных появился. Из БД скачан, с аппсервера приехал или вообще в памяти создан? kig>Вот для чего используется ado, в звязке (производное от TАдоDataset) — TDataSource — TDBGrid.. TDBCombj и т.п.
А теперь объясни — как борландовский рекордсет после передачи преобразуется в адошный? Борланд поставляет своего провайдера?
kig>>>Или Вы себе представили, что в качестве аппсервера выступает OLEDB-провайдер? AVK>>Я себе представляю что для доступа к апп серверу используется OLEDB-провайдер. Иного использования ADO в трехзвенных приложениях я не вижу.
kig>Это почему не видишь? Только тем, что данные, типа, через провайдер поставляются? А чем отличие, ну например, RDS (remote provider), кроме того, что он провайдером называется, от Borland Socket Server? Наборы данных он чего, святым духом пересылает?
Ты мне объясни — каким духом борландовский протокол преобразуется к ado recordset.
kig>Точно так же рекодсеты в виде потоков гонит, или по DCOM, или по HTTP. А вот tcp/ip стыка у него нет, поэтому и не подошел нам.
У кого, у DCOM? Естественно нет. Он работает по любому протоколу, в том числе и по tcp/ip.
kig>Тем более, что Борланд уже представляет, пускай другой, но работающтй способ. И мне им не пользоваться, только потому что он выполнен не в виде оledb-провайдера?
А как он на самом деле выполнен?
kig>Да и по сути — делают они одно и тоже, пока разговор о даныых идет. А вот только возможностей у Борланда перед RDS поболее. Например дернуть объет за метод на серваке RDS не может (на то он и провайдер).
Ну замечательно все, но ADO то тут при чем? Ты хочешь сказать что борландовский клиент сам по своему протоколу связывается с сервером, затем создает ado recordset и заполняет его полученными данными?
AVK>>Что понимается под "гонянием адошных стримов"? Выдергивание готовых рекордсетов по DCOM? kig>по tcp/ip
По своему протоколу? Ну тогда это полнейший идиотизм. Зачем было прикручивать ado не понятно. Если очень хочется пользовать контролы ориентированные на ADO лучше бы было написать своего провайдера или использовать DCOM или вобще с адо не связываться.
kig>см. выше да и зачем переписывать, когда работает. И быстро и устойчиво.
А зачем тогда дотнет? Потому наверное что хочется чтобы проект развивался. Так? А мешанина из борладновских, старых и новых МС технологий приведет к тому что развиваться вам будет сложно.
AVK>>Прежде всего на сервере. А на клиенте по желанию. Лучше конечно тоже.
kig>Да я уже говорил, что на серваке — это объкты. Дернул метод на апп — получил набор (например). Дернул другой метод на апп — отдал изменения, сделанные в нем. А чего он там с ними делает, клиенту по барабану. Сохраняет куда, делает при этом массовые изменения, связанные с логикой... клиент об этом не задумывается.
А нахрена тогда вобще все эти извращения с ADO и Borland Socket Server? Гоняли бы данные напрямую по tcp и не придумывали бы себе лишних проблем.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте IT, Вы писали:
IT>>ADO.NET вполне нормально вписывается в обновлённую идеологию MS распределённых систем (это моё ИМХО, конечно), которая всё больше ориентируется на stateless системы, как на наиболее надёжные, масштабируемые и менее ресурсоёмкие, и уходит от stateful, у которых есть только одно преимущество — быстродейсвие, которое в свою очередь также быстро заканчивается при увеличении нагрузки на систему.
AVK>Все это правильно, но многие вещи не реализуемы stateless в принципе. Тут несколько другой уклон — state нужно выносить в апп сервер. А вот с sql сервером stateful общение совсем не обязательно.
Из нереализуемых вещей мне известно только кеширование и синхронизация работы части сиситемы. Но кеширование это и не stateless и не stateful, это кеширование А вот синхронизацию на stateless действительно не сделаешь, но опять же, при увеличении нагрузки на систему это станет узким местом.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте AndrewVK, Вы писали:
AVK>Понимаешь в чем дело — выборки все равно будут храниться на сервере в памяти. Выигрыш серверных курсоров может быть только в кешировании. А задача кеширования решается сервером приложений на порядок эффективнее. Ну а если курсоры клиентские то все равно даже с ADO вся выборка будет сбрасываться разом и перегружаться при каждом рефреше. Если вспомнить что серверные курсоры появились относительно недавно то я не думаю что при работе с sql-сервером мы получим что то сильно отличное в плане быстродействия от того что было. Просто если раньше процесс получения выборок был автоматическим то в ADO.NET этот процесс можно контролировать.
Да но мы проигрываем в скорости в системах с небольшим количеством пользователей.
Также в удобстве работы.
Так например зачем пользователю при воде элемента справочника знать его ID.
А грузить его в память не совсем хочется так как он не один и может иметь большой размер.
Загружать данные только при необходимости сильно замедлит работу.
Использовать иерхическую структуру справочников тоже не всегда получается.
T>>Я собственно почему поднял этот вопрос в VS.NET есть библиотека ADO 2.7 но котролов для ее использования нет. AVK>ADO идет сама по себе. До недавнего времени это была основная библиотека доступа к данным от MS.
Я имел в виду что она входит в пакет VS.NET.
T>>Может кто работал с этой библиотекой и если да то какие контролы он использовал. AVK>Это зависит от средства разработки. В Дельфи например с ADO работают ее стандартные контролы.
В Делфи пока с этим проблем вобще нет. Но выход Делфи под .Net ожидается только Осенью.
[skip]
AVK>Дальше давай. Ну что приходится из тебя вытягивать подробности клещами. Если тебе известно как работает твой софт это совсем не значит что это известно другим.
Ладно... давай я все по-порядку. А то опять каша получится. :)) ок? А потом на твои замечания отвечу.
Значит так. Когда все только рождалось (в смысле проект затевался) — ну встали извечные вопросы, на чем, как и т.п. писать. И что бы развиваться можно было, и что бы то развитие по трудозатратам было минимальным.... В то время уже во всю орали про дотнет, не помню правда когда его обещали публике в то время, но этот временной лаг был больший, чем мы могли сидеть и ждать, когда его (дотнет) нам преподнесут.
По многим соображениям, в том числе и сображениям пристрастий, был выбрана Д. (Кстати — по твоим словам в полемике с Владом ты как раз и говорил, что с твоей точки зрения, она занимает неплохую нишу — за точность слов не ручаюсь, на за смысл да). В том числе была выбрана многозвенка.
Что имела Д на тот момент для решений такой архитектуры (кстати — появилось-то это все в Д3.01 — кажется 1997 год).
Во-первых, мидас-технологию. Построение многозвенных систем по стыкам tcp/ip, dcom, corba и http-stateless. Нас интересовал только первый вариант. dcom (по поводу tcp/ip транспорта для dcom я в курсе) — проблемы, которые возникают на файрволах (порты). Ну corba сама по себе не интересовала. Http — за собой надо тащить IIS (правда, кажется еще и апач можно — но не знаю, не уверен).
Во-вторых, свой собственный клиентский датасет — TClientDataset. Набор данных, который даже коннекта к БД не имеет — его там пихнуть даже некуда.
В-третьих. Всякое вспомогательное барохло, типа Borland Server Socket, которое умеет перекладывать вызовы tcp/ip на комовские ну и обратно результаты возвращать и неплохо это делать (по поводу написать самим и т.п. — ну на кой черт, если решение уже есть, исходники тоже — пользуй и правь, если надо).
В-четвертых — ну полным полно всякий разных компонентов, в том числе ДБ-аварных, под Д.
Теперь, откуда на клиенте взялся ADO. Казалось бы, пользуй мидасовский датасет (TClientDataset) на клиенте, и все проблемы решены. Так в начале и планировалось. Но!
О дотнете-те то уже вопят. И как-то сложилось мнение, что когда-нибудь, в не такое уж отдаленное время, придется переползать на нее. И что возможностей там будет ого-го. И вот что-то тогда нам подсказывало, что мидасовского датасета там уж точно не будет. :)) А вот ADO какое-то время будет поддерживаться (т.е. тоже казалось, но с большой долей уверенности :) ). А так хотелось с наименьшими затратами перейти, для начала на серваке, на дотнет... По крайней мере, оставить возможность такого перехода без переписывания клинета. А клиента уже потом поменять... Ведь было понятно, что за одну ночь все на дотнет не перейдут — сами пользователя не перейдут сразу, "за одну ночь" (а насильно у заказчиков их туда толкать ну уж очень не хотелось) — значит на клиентский станциях его какое-то время не будет. Т.е все будет происходить тихим эволюционным путем без всяких революций.
Так вот. Вот тогда и пришли соображения, гонять по мидасу не пакеты TClientDataset, а потоки адошных рекордсетов.
Вот отсюда и появился адо на клиенте.
[skip]
AVK>А теперь объясни — как борландовский рекордсет после передачи преобразуется в адошный? Борланд поставляет своего провайдера?
TAdoDataset в Д уже существует, кажется с 5.0. Это обертка вокруг ADODB. Так что проблем больших нет через ADODB.Stream создавать ADODB.Recorset в TAdoDataset и забирать его оттуда.
AVK>Ты мне объясни — каким духом борландовский протокол преобразуется к ado recordset.
Ну если этот протокол позволяет гонять потоки байтов, то чего там преобразовывать? адошный стрим в адошный рекордсет или обратно. Чего, там большие проблемы? Кстати — а встречный вопрос — а RDS по HTTP чего гоняет — рекордсеты в виде потоков? Ну не интерфейсы же адошные он выставляет :)) :))
AVK>По своему протоколу? Ну тогда это полнейший идиотизм.
А почему протокол, который уже представлен Борландом, это обязательно идиотизм?
AVK>Зачем было прикручивать ado не понятно. Если очень хочется пользовать контролы ориентированные на ADO лучше бы было написать своего провайдера или использовать DCOM или вобще с адо не связываться.
Про адо уже сказал.
AVK>Если очень хочется пользовать контролы ориентированные на ADO лучше бы было написать своего провайдера или использовать DCOM или вобще с адо не связываться.
На кой мне черт сдался провайдер? Свой собственный? Который мне еще и писать надо? И при чем здесь контролы, ориентированные на адо? В Д. дб-аварные контролы ориентированы на TDataSet. И он абстрактный. А уж от него — и bde-ешные, и адошные. Да и TClientDataset...
По поводу DCOM — ага — и открывать tcp/ip порты DCOM корпоративной сети на публику в инет.
Еклмн... ну у тебя так — если адо и его пользовать — то это обязательно провайдер для него.
А если я тот же результат получаю меньшими усилиями (писать не надо) — но это не oledb-провайдер — это уже идиотизм? Тем более, что у меня там прекрасная возможность общаться с обектами на апп и дергать их за методы, которые к данным не имеют ни какого отношеня (т.е. не возвращаю наборы данных на клиента и не принимают наборы данных от него).
Здравствуйте kig, Вы писали:
AVK>>А теперь объясни — как борландовский рекордсет после передачи преобразуется в адошный? Борланд поставляет своего провайдера?
kig>TAdoDataset в Д уже существует, кажется с 5.0. Это обертка вокруг ADODB. Так что проблем больших нет через ADODB.Stream создавать ADODB.Recorset в TAdoDataset и забирать его оттуда.
Вот теперь понятно. Надо было с этого начинать. Dataset там кстати появился далеко не с первых версий.
AVK>>По своему протоколу? Ну тогда это полнейший идиотизм. kig>А почему протокол, который уже представлен Борландом, это обязательно идиотизм?
Да нет, я просто только теперь понял как дело обстоит.
AVK>>Если очень хочется пользовать контролы ориентированные на ADO лучше бы было написать своего провайдера или использовать DCOM или вобще с адо не связываться. kig>На кой мне черт сдался провайдер? Свой собственный? Который мне еще и писать надо?
Прозрачно для клиента.
kig> И при чем здесь контролы, ориентированные на адо? В Д. дб-аварные контролы ориентированы на TDataSet. И он абстрактный. А уж от него — и bde-ешные, и адошные. Да и TClientDataset... kig>По поводу DCOM — ага — и открывать tcp/ip порты DCOM корпоративной сети на публику в инет.
Ну откуда я знаю что у тебя клиенты снаружи?
kig>Еклмн... ну у тебя так — если адо и его пользовать — то это обязательно провайдер для него.
Да нет конечно. Просто датасет там появился относительно недавно, когда я уже под адо почти ничего серьезного не писал и я как то сразу про него не подумал.
Здравствуйте IT, Вы писали:
IT>Из нереализуемых вещей мне известно только кеширование и синхронизация работы части сиситемы. Но кеширование это и не stateless и не stateful, это кеширование А вот синхронизацию на stateless действительно не сделаешь, но опять же, при увеличении нагрузки на систему это станет узким местом.
Stateful нужен если нужны session scope объекты на сервере.
Здравствуйте AndrewVK, Вы писали:
AVK>Вот теперь понятно. Надо было с этого начинать. Dataset там кстати появился далеко не с первых версий.
Да... наверно сумбурно все с самого начала объяснял.
Да dataset был еще в 1.0. Вот только в 3.0 они оторвали его от BDE, чем облегчили жисть не только себе, но и нам А адошный, кажется с 5.
[skip]
AVK>Прозрачно для клиента.
Ну вот теперь я думаю, в морде лица клиента можно будет дергание за Борланда заменить на дергание за WebService через SOAP toolkit. Ессно с поправкой на stateless (хотя мы сразу особенно на statefull на клиенте не цеплялись, ну кроме того, что коннект тсп-ишный был постоянный).
AVK>Ну откуда я знаю что у тебя клиенты снаружи?
Здравствуйте Thunder, Вы писали:
T>Да но мы проигрываем в скорости в системах с небольшим количеством пользователей.
На файловой базе.
T>Также в удобстве работы. T>Так например зачем пользователю при воде элемента справочника знать его ID.
А вот тут совсем не понял — пользователь то тут при чем? Скорее пользователю наоборот удобнее, поскольку зная заранее размер выборки можно сделать скроллеры отражающие реальное положение вещей. А зачем ему знать id я честно говоря не понял.
T>А грузить его в память не совсем хочется так как он не один и может иметь большой размер. T>Загружать данные только при необходимости сильно замедлит работу.
Видишь ли какое дело — все равно, если ты не используешь сервернеые курсоры то выборку надо держать на локальной машине. Так что ado.net ничего тут не меняет. Ну а если память жалко — тогда скидывай из datareader не в dataset а на диск, и подгружай по мере необходимости.
T>Использовать иерхическую структуру справочников тоже не всегда получается.
Тем не менее практика показывает что можно обойтись без загрузки огромных массивов данных на клиента. Причина проста — ни один человек все равно не в состоянии воспринять за один раз больше 2-3 килобайт информации. Большие выборки нужны только для автоматической обработки (подготовка отчетов, проводки). А это можно и нужно делать на сервере приложений.
T>Я имел в виду что она входит в пакет VS.NET.
Не входит. Просто нужна для работы.
Здравствуйте kig, Вы писали:
kig>Да... наверно сумбурно все с самого начала объяснял. kig>Да dataset был еще в 1.0. Вот только в 3.0 они оторвали его от BDE, чем облегчили жисть не только себе, но и нам А адошный, кажется с 5.
Я не знаю как в Дельфит, я про адо говорил. Там он появился далеко не с первой версии, а когда появился то был ну очень негибким.
AVK>>Прозрачно для клиента. kig>Ну вот теперь я думаю, в морде лица клиента можно будет дергание за Борланда заменить на дергание за WebService через SOAP toolkit.
А Борланд умеет веб сервисы?
kig>Ессно с поправкой на stateless (хотя мы сразу особенно на statefull на клиенте не цеплялись, ну кроме того, что коннект тсп-ишный был постоянный).
Ну вебсервисы тоже можно сделать stateful.
T>>Также в удобстве работы. T>>Так например зачем пользователю при воде элемента справочника знать его ID. AVK>А вот тут совсем не понял — пользователь то тут при чем? Скорее пользователю наоборот удобнее, поскольку зная заранее размер выборки можно сделать скроллеры отражающие реальное положение вещей. А зачем ему знать id я честно говоря не понял.
Не понял первое предложение.
Ну допустим есть документ в котором нужно ввести клиента и соответствуещего справочника. Я так понимаю это можно сделать или введя код клиента (ID) или выбрать из списка но для этого нужно чтобы база клиентов была загружена в Датасет. Можно конечно использовать использовать иерархию но когда пользователь незнает в какой группе находится контрагент то придется грузить все записи.
Или это еще как — то можно реализовать?
Например загрузка этого справочника на моей машине занимает до 7 с. А есть и другие.
T>>А грузить его в память не совсем хочется так как он не один и может иметь большой размер. T>>Загружать данные только при необходимости сильно замедлит работу. AVK>Видишь ли какое дело — все равно, если ты не используешь сервернеые курсоры то выборку надо держать на локальной машине. Так что ado.net ничего тут не меняет. Ну а если память жалко — тогда скидывай из datareader не в dataset а на диск, и подгружай по мере необходимости.
Та нет памяти мне вобще не жалко. Только при обращении к справочнику нужно каждый раз его грузить, а это время. А если таких справочников на форме 10 — 20 в среднем загрузка одного справочника 3-5 сек. Пользователь только то и будет делать что ждать загрузки очередного справочника. А если справочники загружать в датасет при открытии то там будет немножко устаревшая информация. Я понимаю что она допустим не так часто меняется но все же.
T>>Использовать иерхическую структуру справочников тоже не всегда получается. AVK>Тем не менее практика показывает что можно обойтись без загрузки огромных массивов данных на клиента. Причина проста — ни один человек все равно не в состоянии воспринять за один раз больше 2-3 килобайт информации. Большие выборки нужны только для автоматической обработки (подготовка отчетов, проводки). А это можно и нужно делать на сервере приложений.
Ну тогда ка сделать выбор по типу 1С (если вы знакомы с этим продуктом)
T>>Также в удобстве работы. T>>Так например зачем пользователю при воде элемента справочника знать его ID. AVK>А вот тут совсем не понял — пользователь то тут при чем? Скорее пользователю наоборот удобнее, поскольку зная заранее размер выборки можно сделать скроллеры отражающие реальное положение вещей. А зачем ему знать id я честно говоря не понял.
Не понял первое предложение.
Ну допустим есть документ в котором нужно ввести клиента и соответствуещего справочника. Я так понимаю это можно сделать или введя код клиента (ID) или выбрать из списка но для этого нужно чтобы база клиентов была загружена в Датасет. Можно конечно использовать использовать иерархию но когда пользователь незнает в какой группе находится контрагент то придется грузить все записи.
Или это еще как — то можно реализовать?
Например загрузка этого справочника на моей машине занимает до 7 с. А есть и другие.
T>>А грузить его в память не совсем хочется так как он не один и может иметь большой размер. T>>Загружать данные только при необходимости сильно замедлит работу. AVK>Видишь ли какое дело — все равно, если ты не используешь сервернеые курсоры то выборку надо держать на локальной машине. Так что ado.net ничего тут не меняет. Ну а если память жалко — тогда скидывай из datareader не в dataset а на диск, и подгружай по мере необходимости.
Та нет памяти мне вобще не жалко. Только при обращении к справочнику нужно каждый раз его грузить, а это время. А если таких справочников на форме 10 — 20 в среднем загрузка одного справочника 3-5 сек. Пользователь только то и будет делать что ждать загрузки очередного справочника. А если справочники загружать в датасет при открытии то там будет немножко устаревшая информация. Я понимаю что она допустим не так часто меняется но все же.
T>>Использовать иерхическую структуру справочников тоже не всегда получается. AVK>Тем не менее практика показывает что можно обойтись без загрузки огромных массивов данных на клиента. Причина проста — ни один человек все равно не в состоянии воспринять за один раз больше 2-3 килобайт информации. Большие выборки нужны только для автоматической обработки (подготовка отчетов, проводки). А это можно и нужно делать на сервере приложений.
Ну тогда ка сделать выбор по типу 1С (если вы знакомы с этим продуктом)
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте kig, Вы писали:
kig>>Да... наверно сумбурно все с самого начала объяснял. kig>>Да dataset был еще в 1.0. Вот только в 3.0 они оторвали его от BDE, чем облегчили жисть не только себе, но и нам А адошный, кажется с 5. AVK>Я не знаю как в Дельфит, я про адо говорил. Там он появился далеко не с первой версии, а когда появился то был ну очень негибким.
Чего-то в адо (я не про дотнет) я про датасеты не слышал. Может ты про стирмы адошные говорил? Тогда в MDAC2.5.
Или о чем другом?
AVK>>>Прозрачно для клиента. kig>>Ну вот теперь я думаю, в морде лица клиента можно будет дергание за Борланда заменить на дергание за WebService через SOAP toolkit. AVK>А Борланд умеет веб сервисы?
В 6 чего то умеет... Но я даже не смотрел. Теперь то зачем, когда дотнет есть. Я теперь хочу дергать за вебсервисы, написанные на дотнете. Как я уже говорил — клиент старый остается (с поправкой на SOAP toolkit) — а сервак уже новый будет. Ну правда не совсем Пока останется старое адо, по крайней мере в той части, которая для клиента предназначена.
kig>>Ессно с поправкой на stateless (хотя мы сразу особенно на statefull на клиенте не цеплялись, ну кроме того, что коннект тсп-ишный был постоянный). AVK>Ну вебсервисы тоже можно сделать stateful.
Ты имеешь в виду сохранение данных между запросами (привязка к сессии и т.п.)?
Здравствуйте Аноним, Вы писали:
А>Здравствуйте AndrewVK, Вы писали:
А>Не понял первое предложение. А>Ну допустим есть документ в котором нужно ввести клиента и соответствуещего справочника. Я так понимаю это можно сделать или введя код клиента (ID) или выбрать из списка но для этого нужно чтобы база клиентов была загружена в Датасет. Можно конечно использовать использовать иерархию но когда пользователь незнает в какой группе находится контрагент то придется грузить все записи.
Да, придется. Причем в любом случае, вне зависимости от используемой технологии. А>Или это еще как — то можно реализовать?
Никак. А>Например загрузка этого справочника на моей машине занимает до 7 с. А есть и другие.
Думать как разбить этот справочник на части.
А>Та нет памяти мне вобще не жалко. Только при обращении к справочнику нужно каждый раз его грузить, а это время. А если таких справочников на форме 10 — 20 в среднем загрузка одного справочника 3-5 сек. Пользователь только то и будет делать что ждать загрузки очередного справочника. А если справочники загружать в датасет при открытии то там будет немножко устаревшая информация. Я понимаю что она допустим не так часто меняется но все же.
Можно завести в специальной таблице запись в которую писать дату последнего изменения справочника и при каждом обращении сверять эту дату с тем что в памяти или на локальном диске. Если отличается то справочник нужно перегрузить. Поскольку справочники изменяют как правило редко то получишь весьма существенный выигрыш в быстродействии.
А>Ну тогда ка сделать выбор по типу 1С (если вы знакомы с этим продуктом)
Не то слово, будь он неладен. Я тебе скажу как это сделано там, а ты уж решай, стоит ли оно того. 1С при обращении к справочнику просто копирует файл справочника с индексами. При каждом обращении сверяет дату модификации локального файла и файла в базе и если в базе файл другой то копирует его по новой. Ну а работает уже с локальной дбфкой. Ну и справочники в 1С все иерархические.
Здравствуйте kig, Вы писали:
kig>>>Ессно с поправкой на stateless (хотя мы сразу особенно на statefull на клиенте не цеплялись, ну кроме того, что коннект тсп-ишный был постоянный). AVK>>Ну вебсервисы тоже можно сделать stateful. kig>Ты имеешь в виду сохранение данных между запросами (привязка к сессии и т.п.)?
Да
Здравствуйте AndrewVK, Вы писали:
AVK>Не то слово, будь он неладен. Я тебе скажу как это сделано там, а ты уж решай, стоит ли оно того. 1С при обращении к справочнику просто копирует файл справочника с индексами. При каждом обращении сверяет дату модификации локального файла и файла в базе и если в базе файл другой то копирует его по новой. Ну а работает уже с локальной дбфкой. Ну и справочники в 1С все иерархические.
А что так сумбурно по поводу 1С? По моему не плохое средство для быстрой разработки экономического и бухгалтерского ПО. Я просто занимаюсь внедрением 1С на средних и малых предприятиях уже более 3 лет. И сомневаюсь что там действительно так реализована работа со справочниками и другими объектами Журналами, Журналами расчетов. А как же в веорсии SQL хотя я знаю 1с использует SQL только как хранилище данных.
И если 1с копирует файлы может ты знаеш где они находятся?.
Здравствуйте Thunder, Вы писали:
T>А что так сумбурно по поводу 1С? По моему не плохое средство для быстрой разработки экономического и бухгалтерского ПО.
Я где то сказал что но плохое?
T> Я просто занимаюсь внедрением 1С на средних и малых предприятиях уже более 3 лет.
Я тоже.
T> И сомневаюсь что там действительно так реализована работа со справочниками и другими объектами Журналами, Журналами расчетов.
Не сомневайся. И посмотри при запущенной 1С в temp-каталог — увидишь там половину базы. Журналов кстати нет — есть один единственый общий журнал, остальные получаются выборками из него.
T> А как же в веорсии SQL хотя я знаю 1с использует SQL только как хранилище данных.
Коли знаешь то чего спрашиваешь? Также копируется в dbf на диск.
T>И если 1с копирует файлы может ты знаеш где они находятся?.
А ты догадайся с трех раз
AVK>Не сомневайся. И посмотри при запущенной 1С в temp-каталог — увидишь там половину базы. Журналов кстати нет — есть один единственый общий журнал, остальные получаются выборками из него.
Весе темпы обшарил но не нашол таблиц ну ладно может они в памяти держатся.
Видел только что создается файл меньше 1К и пустой каталог. Да и место на диске не уменьшается.
Это так может я конечно и не прав. Спасибо за интерестную дискусию.
Может что еще посоветуеш (если я еще не надоел)
И вот как я придумал работать:
1. Заводим дополнительную таблицу
где будет одно поле с именем всех таблиц,
другое с датой последнего обновления.
2. Заводим во всех таблицах 2 дополнительных поля
в первом будет фиксироватся дата и время последнего обновления поля,
во втором дата и время последнего блокирования.
Ну и естествено исходя из этих данных будет ненужно загружать
повторно все данные а только измененные. А их будет совсем немного.
Это все можно навешать на таймер ~1мин (вычеслается пробным путем).
И таким образом будут поддерживатся актуальные данные.
При выходе из программы можно будет скидывать весь датасет на диск
и при следуещем запуске просто считывать данные и обновить устаревшие.
Но это не обязательно.
Еще надо будет подумать как обновлять удаленные данные.
Можно завести еще одну таблицу.
Но при таком раскладе у меня возникает вопрос где брать дату и время обновления? :???:
С машины пользователя некоректно так как оно может сильно отличатся или быть неправельным.
Единственно что я придумал это запустить програмульку на сервере которая будет отдавать время и дату.
Здравствуйте Гром Олег Васильевич, Вы писали:
ГОВ>Весе темпы обшарил но не нашол таблиц ну ладно может они в памяти держатся.
Не там наверное искал. Набери в командной строке set temp.
ГОВ>Видел только что создается файл меньше 1К и пустой каталог. Да и место на диске не уменьшается.
Да нет, там должно быть сотни полторы файлов.
ГОВ>Это так может я конечно и не прав. Спасибо за интерестную дискусию. ГОВ>Может что еще посоветуеш (если я еще не надоел) ГОВ>И вот как я придумал работать: ГОВ>1. Заводим дополнительную таблицу ГОВ>где будет одно поле с именем всех таблиц, ГОВ>другое с датой последнего обновления.
Нормально.
ГОВ>2. Заводим во всех таблицах 2 дополнительных поля ГОВ>в первом будет фиксироватся дата и время последнего обновления поля,
Я думаю это излишне, разве только для очень больших справочников. ГОВ>во втором дата и время последнего блокирования.
А это зачем?
ГОВ>Ну и естествено исходя из этих данных будет ненужно загружать ГОВ>повторно все данные а только измененные. А их будет совсем немного. ГОВ>Это все можно навешать на таймер ~1мин (вычеслается пробным путем).
Зачем? Можно просто при каждом обращении. Если только не обновлять датагрид сам по себе.
ГОВ>При выходе из программы можно будет скидывать весь датасет на диск ГОВ>и при следуещем запуске просто считывать данные и обновить устаревшие. ГОВ>Но это не обязательно.
Да, это тоже наверное излишне. Разве только если программа работает через инет по медленным каналам.
ГОВ>Но при таком раскладе у меня возникает вопрос где брать дату и время обновления?
ГОВ>С машины пользователя некоректно так как оно может сильно отличатся или быть неправельным. ГОВ>Единственно что я придумал это запустить програмульку на сервере которая будет отдавать время и дату.
ГОВ>Может что-то подскажеш. ГОВ>Зарание благодарен.
GetDate() прямо в запросе для Transact SQL. Можно прямо в триггер на добавление.
Если нам не помогут, то мы тоже никого не пощадим.
Особенно с Identity полями... Особенно когда помимо основоной записи нужно вставить еще десяток подчиненных...
Пока останется старое адо, по крайней мере в той части, которая для клиента предназначена.
