[AlnZ]

Цитата: что локальный ключ HASP не видится в Линуксе...

Потому-что он видтся через драйвер. Давально хитрый. Можешь посмотреть в "Диспетчер задач" (включить "Показать скрытые устройства", там будет такая хренотень HaspNt)

Цитата: Не стану спорить. Моих скромных способностей просто не хватит, чтобы написать полноценное многопользовательское приложение, в котором в качестве хранилища данных используется БД Jet. Могу только подивиться, как у вас там организован тридинг, неужто в БД пишет единственная нить? Это ж какая самоотверженность: написать фактически свою СУБД... Или вы по пути 1С 7.7 пошли? Нет уж, лучше мы по старинке... через SQL Server...

и

Цитата: Да вроде все-таки владею И как справедливо сказано, любой универсальный интерфейс доступа к данным потому и универсальный, что скрывает детали реализации. Но вы используете Jet вместо того чтобы использовать, ну, например, Firebird. И при этом, сдается мне, не совсем понимаете, как же это в итоге все работает. А зря. Я, конечно, не призываю отказываться от всяческих прослоек, но программист успешен тогда, когда он задумывается о том, как работают все прослойки в его проекте. Совсем хорошо, когда он не только задумывается, но и понимает ;)

Последняя цитат - просто лирика? Ведь сначала речь пошла что я свой движек изобретаю. Как оказалось что не так, значит я вообще нихрена не понимаю, раз "прослойку использую".

Цитата: Но все же чаще работает, чем нет...

По моему вы сдесь путате установку патча с установкой драйвера...

Цитата: ну вроде бы на рсдн соотношение было 48/52% или около того, что, согласитесь, никак не "подавляющее большинство" ;)

Не соглашусь. Там было 5-10вариантов ответа. Однозначно нет(больше 50ти), однозначно да (<10), и еще куча разных вариантов да,нет, иногда...

Цитата: Я вот не пишу (на практике). Потому, наверное, что понимаю как надо писать.

"Я не пишу, потому-что знаю" Поверю, что не наоборот Вот только не судите о том, что не пишете! (или хотя-бы по существу - что же за проблемы такие?) Не знаешь(уверен) - не пиши...

Цитата: И отлаживать проще, естественно. Но проще всего, все-таки .Net, я настаиваю. И только его я сравниваю с COMом.

Трети раз - Да почему вы сравнивате несравнимое??? Вы можете из 1С, JavaScript, MSAccess, MSExcel, 1С вызывать объекты от .NET? Только в том случае, если они уже сответствуют спецификации COM!!! Или вы сравниваете COM написанный под .NET с COM, написанным в дельфах или старой студии?
Хватит сравнивть среду и стандарт библиотеки!
COM - соглашение о вызовах в между программами, а .NET технология для создания программ!

Цитата: Учитывая, что ХП можно писать на любом .Net языке, простор для маневра в этом вопросе все равно остается...

Ну вы даете!!! А то, что ХП почти всех популярных движков отличаться вам не известно? И при смене движка придется ХП править, то-же?

Цитата: Жаль, если вы действительно не понимаете, чем приходится расплачиваться за "универсальность". И жаль, если вы не понимаете принципиальной разницы между тем же мускулем и Джетом.

Одни наезды и никакой информации Ну и чего же я потерял с приобритением этой "универсальности"? Да вообще, что я не так сделал? С любым движком первое звено в моем трехзвенном приложении в любом случае бедет только хранилищем. И запросы будут в основном select..., update... и delete... . И ХП не используются не из-за "универсальности", а только из-за того, что реализацией безнес-логики должно заниматься второе звено!!! И за "вы не понимаете принципиальной разницы между тем же мускулем и Джетом" Ответь за слова! Хотя-бы малюсенький прмер (где то это уже было ), в чем же разница, в использовании как первое звено Jet или мускул... Только не надо говорить о кроссплатформенности, речь шла о технологии...

Цитата: Очень глубокое заблуждение. ODBC не осуществляет работу ни с чем. Он только транслирует свои вызовы в вызовы соответствующих движков СУБД, тем самым скрывая детали реализации от пользователя. И мне известно только одна СУБД, для которой ODBC-провайдер тривиален, ибо ODBC ее нативный интерфейс. Ее разработали, как ни странно, вовсе не MS, а IBM. И вот как раз обращение к .dbf'у ODBC передает Jet'у, который и осуществляет работу. А вот BDE работает с dbf'ом без Jet'а, самостоятельно. Вобщем, про это нужно книжки читать, а не форумы.

Ну вы совсем запутались А ещё книжки читать рекомендуете
Хотя, начало было верным!
"Он только транслирует свои вызовы в вызовы соответствующих движков СУБД, тем самым скрывая детали реализации от пользователя." А Jet разве не тем-же заниматеся, когда вы DBF через него открываете? Или понятие ISAM или ODBC драйвер вам не знакомо? И то, что BDF-ный ISAM драйвер ставится отдельно, вам не знакомо? (и, кстате, после установки его нет в системе!) Причем, если вы посмотрите доступные по умолчанию DAO провайдеры в системе, то увидите отдельно Jet (у которого, правда уже есть несколько ISAM драеверов), отдельно ODBC.

Цитата: Конечно не согласен.

Добавили бы ещё предложение хоть... Почему. С чем он ещё работает... Почему при настройке Jet-провайдера я моку указать только MDB файл, но не DBF? И на каком основании был сделан вывод, что Jet нативно работает с DBF?

Цитата: И вот как раз обращение к .dbf'у ODBC передает Jet'у, который и осуществляет работу.

Блин, ну вы даете!!! Действительно у вас каша в голове! С точностью до наоборот!!!
Поясню: ODBC, DAO и RDO, ADO - все это интерфейсы к движкам баз данных через специальные драйвера (провайдеры). Но ADO, например, ище имеет и провайдер для доступа к данным через ODBC. Jet, собстевно движек. Который, сам, правда, уммет обращаться к другим форматам через ODBC или известный ему ISAM драйвер (можете заметить, мы их установку вибираем при установке студии или того-же VB6). И доступ в DBF ODBC делает не через Jet, а через известные ему ODBC драйверы. Можешь проверить - в "панели управления" выбери "Источники данных (ODBC)"
Дополню еще ODBC гораздо старее Jet. И был в системе ещё в Win3.1, когда ADO и не пахло...
И следующая картинка, по вашему, неправильная?
[img=http://img295.**************/img295/5346/img00001ec5.th.gif]

Цитата: .. А Microsoft тем временем продолжает упорно обещать отказаться от COM, как и от WinAPI в пользу .Net'а

Если я не ошибаюсь, первое такое обещание было в самом начале этого десятилетия... Итого, уже 5-7 лет обещает. Вот только почему никаких подвижек в эту сторону не видно? И API новые ими-же создаются, и COM сервера... Да и фреймворк "почему-то" сам API и вызывает!
Фреймоврк - это именно та самая "прослойка скрывающая детали реализации" (вы одну уже вспоминали). Во всяком случае, пока. Но лет 10 еще так и будет. Или для вас фреймворк не новый слой абстракции, а именно альтернатива API и COM?
А обещаниями сыт не будешь! Что делала Microsoft, когда отказалась от ODBC в пользу DAO и RDO? Прекращали их развитие! Та же участь их постигла в пользу ADO... Аналогично они поступили и с 98ой виндой... и не дотнетовскими языками в своей студии. И А API развиваются и умирать не собираются! Так что больше верь Майкрософту, они и не такое наобещают!