| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Вставка записи при уникальном индексе. [Access]
Ш-К © (2007-03-05 02:51:00)Вставляю из Delphi около 1000 записей. Таблица имеет уникальный индекс по 2 полям.
Что сделать, чтоб не ругался при вставке неуникальной записи, а просто игнорировал вставку?
ЮЮ (2007-03-09 09:28:00) [1]>sniknik ©
>Коля, тут, похоже, тот случай, когда бисер следует поберечь ;)
Угу, экономьте, помечите перед собой :)
MsGuns (2007-03-07 21:04:00) [2]>ЮЮ © (07.03.07 05:13) [26]
>И чего такого в Paradox-е нет (из перечисленного), что есть в приличном скл-сервере Акцесе :)
Всего перечисленного.
>не верю, что активно работаешь в многопользовательском режиме в приложнии "MS Access 95(98)".
"Блажен кто верует и горе тому, кто не верит" (с)
>А это больше похоже на клиентскую работу с курсором. Для этого специально TClientDataSet придуман.
Только при чем тут вообще парадокс ? Или мы творог из вареников добываем ?
>sniknik ©
Коля, тут, похоже, тот случай, когда бисер следует поберечь ;)
sniknik (2007-03-07 08:42:00) [3]> TTable сюда зачем приплетать? Особенно после [19] :)
потому что на нем ВИДНО, по разнице работы тейблов в разных технологиях хорошо видна разница в их принципах.
> Для этого специально TClientDataSet придуман.
это уже не BDE, это уже мидас. часть технологии трехзвенок, сервер которого кстати тоже можно рассматривать как своеобразный sql сервер... даже при том, что написан он не какойто конторой а самим программистом. (и даже при том что ни одного sql запроса им не было использовано... просто в этом случае можно принять что все они были простые на полное открытие таблиц)
...
ну и т.д. каждое притянутое за уши "доказательство" опровергать смысла как уже решили нет... (сколько не говори, а когда откидывается все что обьясняет, и берется исключение (о котором и так говорилось что это работает несколько по другому) для контраргументов. ну это о чемто да говорит)
ЮЮ (2007-03-07 05:13:00) [4][25] MsGuns © (06.03.07 16:16)
> Тем, что отсутствуют как класс такие фундаментальные вещи как метаданные, бизнес-логика, транзакции, счетчики и еще
> ооочень много того, что есть в любом мало-мальски приличном скл-сервере (например, в Акцесе)
И чего такого в Paradox-е нет (из перечисленного), что есть в приличном скл-сервере Акцесе :)
> А я вот не "сталкивался", а работаю периодически лет 5. И ни одного "слета" - я исключение ?
не верю, что активно работаешь в многопользовательском режиме в приложнии "MS Access 95(98)".
> Хотя бы сортировка по произвольному порядку без правки текста
> запроса и переоткрыти
А это больше похоже на клиентскую работу с курсором. Для этого специально TClientDataSet придуман.
> Действительно, скопировал gdb кликнул на нем двойничком и получил фигу с медом. Игде там интербуз ?, - ох, дурют
> народ !
Лучше HexEditor-ом (если Блокноту не доверяешь) открыть mdb, "откорректировать" и сохранить. И пусть jet отдыхает :)
[24] sniknik © (06.03.07 09:14)
> главное отличие, в принципе работы, открытие таблицы в файл серверном открывает файл и возвращает его хендл для дальнейшей
> работы. в клиент серверном тоже открытие таблицы считывает ее в память формирует рекордсет
Работая с MS SQL + BDE я, по твоей логиге, работаю не с сервером, а с файлом только потому, что БДЕ сохраняет курсор в файл, а не хранит в памяти?
Да и hDBIDb это хэндл всё-таки для логических оперций над таблицей БД, а не файлом ОС.
Jet-у, можно подумать хендл файла не нужен и изменения он вносит божественным способом, просто показав mdb-файлу текст запроса.
То что BDE API открыт на уровне доступа к файлу БД, а JET-а - на уровне доступа к курсору, говорит лишь о степени закрытости технологий второго.
Главное отличие сервера БД от файла БД, ИМХО, предостоавление только "логических" данных и полное отсутвие доступа клиентского приложения к физическому файлу. Сам Сервер БД на серевере является уже клиентом, работющим с файлом. Как и любой Embeded "сервер" - это просто "навороченный" TDBF.
MsGuns (2007-03-06 16:16:00) [5]>ЮЮ © (06.03.07 03:02) [23]
>Среди множества слов так и не увидел объяснения, позволивщего хоть чуть-чуть увидеть в mdb-файле в расшаренной папки намёки на сервер БД.
Действительно, скрпировал gdb кликнул на нем двойничком и получил фигу с медом. Игде там интербуз ?, - ох, дурют народ !
>Я в своё время не один раз сталкивался как MS Access(95-98) напрочь убивал свои базы при совместном использовании даже 2-мя пользователями.
А я вот не "сталкивался", а работаю периодически лет 5. И ни одного "слета" - я исключение ?
>И чем отличается в этом отношении Paradox-овская база (1 файл или много - не тот уровень отличий).
Тем, что отсутствуют как класс такие фундаментальные вещи как метаданные, бизнес-логика, транзакции, счетчики и еще ооочень много того, что есть в любом мало-мальски приличном скл-сервере (например, в Акцесе)
>Я имел в виду разницы в коде с точки зрения TDataSeta-а и его методов, а не механизмов взаимодействия клиента с БД. Укажи, если такой зрячий :)
Имеется, и именно с точки зрения самого датасета. Хотя бы сортировка по произвольному порядку без правки текста запроса и переоткрытия или тот же ReQuery. Кроме того, адошный датасет менее капризен в плане "редактируемости". Да много чего еще..
sniknik (2007-03-06 09:14:00) [6]> Среди множества слов так и не увидел объяснения, позволивщего хоть чуть-чуть увидеть в mdb-файле в расшаренной папки
> намёки на сервер БД.
естественно, ты же специально закрываешь глаза встречая такое обьяснение... а все на что не закрыл извращаеш.
итак последняя попытка (больше не будет т.к. человеку игнорирующему доводы обьяснить ничего в принципе невозможно).
во первых где я говорил что файл mdb в расшаренной папке это сервер БД? не было такого, говорилось про ядро jet, COM обьект, то что его можно рассматривать как sql сервер, по поведению, по тому как с ним работать (со всеми возможными оговорками говорилось, что это вовсе не реальный сервер, и про разные режимы упоминалось... и кстати если уж на то пошло он и парадоксом работает также. т.е. открывая джетом файл *.db будет то же поведение).
главное отличие, в принципе работы, открытие таблицы в файл серверном открывает файл и возвращает его хендл для дальнейшей работы, размер таблицы на время открытия не влияет, в клиент серверном тоже открытие таблицы считывает ее в память формирует рекордсет который передается через ядро/sql сервер на клиента (пусть даже этот клиент тут же на сервере, т.е. оба на одной машине), размер таблицы очень даже влияет на время открытия.
т.е. разница в принципах, про которую знать желательно всем, и чем раньше тем лучше. а не просто тупо заучить "sql это круто!", на все есть причины, и та о которой я говорю одна из тех которая в одном случае делает запросы выгоднее (и единственно правильным способом работы), в другом и простое открытие таблицы пойдет, и даже часто лучше пойдет чем запрос sql.
> Я имел в виду разницы в коде с точки зрения TDataSeta-а и его методов, а не механизмов взаимодействия клиента с БД.
стрелки переводишь? именно о механизме взаимодействия клиента с ядром/sql серверому нас речь...
но в общем и в методах датасетов есть различия, например Sort возможный при работе с рекордсетом (потому как он в памяти находится) и невозможный с файлами у файл серверного метода (либо при настройках псевдо файл сервера у jet). и обратная сторона, индексы, подключение индекса возможно у файлов (если эти индексы есть конечно) и невозможно у рекордсета т.к. его индексы остались на сервере, а на клиенте их попросту нет.
(может и еще есть, но думать неохота на эту тему, т.к. это все одно придирка, очередное увиливание в нежелании признать чужую правоту)
> З.Ы. Почему остальные мастера БД молчат? :)
ну это надеюсь тебе ктонибудь другой объяснит. без меня. ;о)
ЮЮ (2007-03-06 03:02:00) [7]берешь таблицу с парой миллионов записей для каждого случая, подключаешь ее и делаешь Table1.Open
TTable сюда зачем приплетать? Особенно после [19] :)
я всетаки склонен думать недопонимаешь.... иначе бы не пытался обьяснить.
Среди множества слов так и не увидел объяснения, позволивщего хоть чуть-чуть увидеть в mdb-файле в расшаренной папки намёки на сервер БД.
Я в своё время не один раз сталкивался как MS Access(95-98) напрочь убивал свои базы при совместном использовании даже 2-мя пользователями.
И чем отличается в этом отношении Paradox-овская база (1 файл или много - не тот уровень отличий).
А разница, между тем, имеется. Хоть ты ее и не видишь ;)
Я имел в виду разницы в коде с точки зрения TDataSeta-а и его методов, а не механизмов взаимодействия клиента с БД. Укажи, если такой зрячий :)
З.Ы. Почему остальные мастера БД молчат? :)
MsGuns (2007-03-05 16:35:00) [8]>ЮЮ © (05.03.07 13:21) [20]
>Используя TQuery в BDE и TAdoDataSet в ADO я лично вообще не вижу разницы в клиент-серверных приложениях ни при работе с Paradox+BDE, ни при MS SQL + BDE, ни при MS SQL+ADO.
А разница, между тем, имеется. Хоть ты ее и не видишь ;)
sniknik (2007-03-05 13:37:00) [9]> не вижу разницы в клиент-серверных приложениях ни при работе с Paradox+BDE, ни при MS SQL + BDE, ни при MS SQL+ADO
берешь таблицу с парой миллионов записей для каждого случая, подключаешь ее и делаешь Table1.Open в случае с Paradox+BDE, и ADOTable1.Open в случае с MS SQL+ADO (или MS SQL+Jet при стандартных настройках, про настраиваемость выше упоминал) и ты эту разницу не только увидишь ты ее компьютерными герцами прочуствуеш...
(и неважно на локальной машине парадоксовская таблица/база mdb лежит или в расшарке на сервере (mssql несколько особняком но тоже неважно где находится))
> Буквоедствуя я. :)
я всетаки склонен думать недопонимаешь.... иначе бы не пытался обьяснить.
> MS SQL + BDE
про "исключения" см. [14] второй абзац.
ЮЮ (2007-03-05 13:21:00) [10]Споришь ты. Буквоедствуя я. :)
Используя TQuery в BDE и TAdoDataSet в ADO я лично вообще не вижу разницы в клиент-серверных приложениях ни при работе с Paradox+BDE, ни при MS SQL + BDE, ни при MS SQL+ADO. Разве что MS SQL позволяет сам гораздо больше вкусностей.
sniknik (2007-03-05 13:09:00) [11]> На низком уровне всё равно файловые операции над mdb, расположенном на другом компьютере выполняют
> процессы клиента ведь так?
чтобы такого не было есть пара приведенных выше обьектов (+ RDS в ADO)... которые обычно никто не использует (и правильно, я пробовал, мелкософт их сделал сложными в использовании, специально имхо, чтоб активнее на mssql пересаживались ;)).
p.s. Sergey13 был прав, ты именно споришь. пытаешься "продавить" свою точку зрения притягивая чуть ли не за уши любые аргументы к теме не относящиеся, "буквоедствуеш". ну вот какая разница как там что работает на низком уровне? когда говорилось о принципе работы с самим обьектом. про взаимодействие программы с ADO jet/BDE paradox (?).
сколько бы начинающих не начинало с TADOTable/избежало проблем/тормозов если бы им вовремя сказали "работай с этим как с клиент сервером, несмотря на то что файл базы у тебя локально/доступ по расшарке, читай сразу про технологию клиент сервера, смотри примеры по нему, она jet-у гораздо ближе, чем то что ты сейчас читаешь про BDE и тупо (пока не понимаешь) переносишь на ADO".
ну раз спор, то нафик, переубеждать закостеневшие взгляды на вещи себе дороже. и бессмысленно.
MsGuns (2007-03-05 12:41:00) [12]Акцесс не позволяет писать о одну таблицу одновременно нескольким пользователям, поэтому можно "подожиться" на то, что связка "проверить - добавить - перечитать" выполнится на неизмененной таблице. Хотя, можно все это "завернуть" в одну транзакцию для надежности.
Что же касается дубликатов..
"Мягкий" алгоритм должен перед Insert включать Select Key1,Key2 с проверкой наличия возвращенной записи,
"Жесткий" проверку не делает, сразу добавляя новую запись - в этом случае роль "цербера" должен выполнить сервер (Акцесс), "выплюнув" запрос с соответсвующим сообщением, "спрятать" который можно, сунув выполение вставки в защищенный блок.
В обоих случаях "тормозов" быть не может. А если они есть, то см. свою программу, не исключено, например, что переоткрытие отображаемого датасета делается не зависимо от того, успешно ли была вставлена запись.
ЮЮ (2007-03-05 12:28:00) [13]На низком уровне всё равно файловые операции над mdb, расположенном на другом компьютере выполняют процессы клиента ведь так? Именно в этом я и вижу главное отличие клиент-сервера, где только сервер имеет доступ к физическим данным, а клиент - к логическим, от файл-сервера, где клиент модифицирует физический файл. БДЕ API тоде не дает доступа к данным на уровне физического файла, тем не менее его сервером не называют и клянут по чём поподя :)
sniknik (2007-03-05 12:17:00) [14]Sergey13 © (05.03.07 11:55) [15]
где спор?
я не спорю, мне вообще пофиг кто как считает (хотят сложностей/проблем... да пожалуйста), но он вроде как спрашивает, я вроде как пытаюсь обьяснить...
> но не объясняется ли такая "сервероподобная" работа с аксесом тем ...
может быть, но скорее всего нет, вернее не единственная причина. про становление/разработку ADO когдато читал, там было что писали его под MSSQL и access до кучи, jet тоже в тоже время разрабатывали (до этого был DAO. счас он часть jet, и скорее всего только для совместимости старого и остался)... ну и..., вот как увязать совершенно разные принципы в одном продукте? ну судя по всему то что мы сейчас имеем это и есть решение от мелкософта, сделать локальный движок так чтобы работать с ним как с sql сервером. тогда не нужны дополнительные механизмы/деления на файл/клиент сервер (тем более файл устарел и отмирает) и т.д. все стало гораздо проще при таком решении.
т.е. скорее обьясняется это решением мелкосовта перейти на новое и отойти от старых технологий весде, даже там где они в принципе и не очень мешают.
Sergey13 (2007-03-05 11:55:00) [15]> [14] sniknik © (05.03.07 11:50)
Я может чего не понимаю в вашем с ЮЮ споре, но не объясняется ли такая "сервероподобная" работа с аксесом тем, что MDB это однофайловая БД, в отличии от "таблично-файловых" (типа xBase).
sniknik (2007-03-05 11:50:00) [16]> Работая с парадоксом в сети через BDE
не в сети, а неважно где, даже если все локально.
открытие таблицы, эту таблицу попросту открывает как файл...
в отличие от jet (стандартный вариант рассматриваем, настройками можно изменить), который открытие таблицы в компоненте преобразовывает в запрос к ядру, и это ядро возвращает рекордсет, копию данных в памяти. так же как любой другой sql сервер. т.е. принцип работы клиент серверный а не файл сервер. и сервером здесь выступает ядро/COM обьект jet...
и дальнейшее общение идет только запросами через это ядро, BDE же может (и это в нем выгоднее) общатся/и общается с таблицами как с файлами. (есть и исключения, все зависит от провайдера данных (или как там в BDE?), но принцип у "нативе" драйверов всетаки файл серверный)
разве не видиш разницу?
да в общем неважно, можеш думать как хочеш, просто рассматривать/работать с jet как sql сервером, гораздо проще/логичнее/можно избежать кучи проблем, чем по другому, рассматривая mdb просто как файл на своей машине/в сети.
ЮЮ (2007-03-05 10:01:00) [17]Тогда не вижу никакой серверности. Работая с парадоксом в сети через BDE ( такое же ядро, удаленное и независимое от программы с которым общаешься с помощью запросов...) имею такой же "сервер", что и с mdb через Jet :)
sniknik (2007-03-05 09:48:00) [18]> Т.е. Access-а может и не быть, но jet присутствовать обязан?
естественно. он по умолчанию практически всегда и ставится вместе с операционкой.
> И клиентский jet работает не с mdb файлом а с "серверным" jet-ом?
где я такое говорил? не тупи. рассматривалась программа и jet (1 копия), неважно где он стоит на твоей машине или на другой, по поведению это в любом случае сервер. и по умолчанию всегда используется локальный, для работы же с удаленным нужны упоминавшиеся обьекты (с ними работа по DCOM), , но их практически не используют... сложно. проще файл расшарить.
ЮЮ (2007-03-05 09:14:00) [19]> [10] sniknik © (05.03.07 09:03)
Т.е. Access-а может и не быть, но jet присутствовать обязан? И клиентский jet работает не с mdb файлом а с "серверным" jet-ом?
Или все-же несколько клиентских jet-ов работают напрямую с серверным mdb файлом, использую заложенный в него механизм многопользовательского доступа? Т.е. так же как BDE с парадоксовскими файлами?
sniknik (2007-03-05 09:03:00) [20]> Полагаю, что речь здесь все-таки не об Access, а о mdb-файлах
я говорил о jet, он давно уже для меня олицетворение Access ;о), а программа аксесс настолько редко исползуема, что говоря о ней специально упоминаю что это именно о программе речь.
> На файл-сервере может и не оказаться никакого Access
естественно, может не быть, нет и не надо. речь не о нем а о движке аксесс, jet. перечитай 1 абзац из [7].
| |
Страницы: 