Вопрос:
DW.NET работает с среде NetFramework без PBVM или ее установка обязательна ? Если без нее не работает, то думаю, что DW.NET - это обычная обвязка DataWindow Control для ДотНета (как ActiveX).

Честно говоря я так и не вьехал в суть спора :) Раз PBVM под DataWindow.NET ставиться, то это старый обычный ActiveX DataWindow, обернутый интерфейсами .NET, что есть хорошо: очень высокая скорость работы и низкая требовательность к ресурсам, в отличие от чистых .NET компонентов (меня всегда веселило, что QuantumGrid.NET или UltraGrid.Net тормозят со страшной силой при отрисовке и кушают по 30 метров памяти, хотя с другой стороны оно и понятно - идеология сборщика мусора в GUI - на этом еще и Java споткнулась неплохо). С другой стороны если посмотреть, то толку от DW.NET тоже не особо много - небось он со своим Transactional object работает и ему ADO.NET побоку ? :) Если это так, то я бы назвал DW.NET чисто маркетинговым ходом, как говориться сделали, чтобы было и никто не мог Sybase заявить, что они отстали от модных MS технологий. С учетом того, что ADO.NET не так уж и плох, да и ко всему прочему по принципам кое в чем содран с принципов DataStore, а кое в чем даже неплохо расширен, то думаю что MS публика предпочтет использовать его вместе с гридами .NET.

Лично я считаю, что кстати .NET вообще не катит под написание мордочек под БД. Веб лепить вот милое дело, а GUI делать на нем - чистейшей воды мазохизм (так же, как в Delphi и Java). Меня например именно своей мощностью DW, простотой реализации ООП и PowerScript, прозрачным элегантным доступом к данным и встроенным SQL и привлекает PB. По моему здесь все четко и красиво (пусть и со своими грехами), в отличие от универсальных средств 3 в одном, где через одно можно все, но только через заднее место.

авторDW, что еще есть в PB такого же ценного? Все остальное мелочи, из-за которых даже споры разводить не интересно.
Я вот к примеру вчера ровно за 20 минут забабацал себе на PB компонент для организации сложных окон-визардов, причем получилось все красиво в рунтайме и удобно в дизайнтайме. Немножно повозил мышкой, немножко кода пописал (порядка 50 строчек несложного кода) и вуаля. На Delphi подобный компонент-визард я лепил порядка 4 дней, никакой мышки - голый код (500 строк), плюс еще использование WinApi для корректной отрисовки компонентов VCL с переключающихся страничек, так как сами они глючили вследствие того, что Delphi не всегда правильно обрабатывал сообщения WINAPI. Плюс потом умучался отлаживать все это дело в дизайн и рунтайм режимах. Сюда до кучи можно вспомнить POST-обработку событий и методов в PB, в отличие от Delphi, в котором приходиться в классе формы (или обьекту с handle) прописывать метод MESSAGE с собственным кодом сообщения, в нем прописывать необходимую пост-обработку, а далее его использовать для вызова через функцию WinApi POSTMESSAGE. Ну и встроенный SQL ту да же до кучи: вся суета на выполнения SQL через компонентную технологию сильно напрягает, SQL в виде стринга занеси, параметры ручками определи, и т.д. Можно конечно на формочки на каждый используемый SQL компонент кидать и в визуале его рисовать, но возникает закономерный вопрос - а не жирно ли из за вызова например одной ХП держать на время жизни формы лишний обьект (опять же это наиболее будет актуально для Java и C#).

авторК сожалению, в ЛЮБОМ крупном проекте есть 10-20% "тяжелых" алгоритмов, которые отравляют жизнь.
Ммм ... вроде давно уже всякие крупные 2-звенные проекты пишу (пусть и не так давно на PB), но вот ни разу на эти 10-20% не наталкивался. Все у меня как то тяжелые алгоритмы или на СУБД уведены или если уж чего то специфическое, то всегда DLL/COM/OLE написать не долго хотя бы на том же Delphi. Так что в клиентской части у меня кроме интерфейсной части и примитивной клиентской бизнес-логики ничего и нет. Может быть приведете примеры тяжелых алгоритмов в клиентском приложении ?

IMHO Для рисования мордочек .NET бесполезен, как и Java. Возможностей вроде как много, требований к ресурсам и геммору честно говоря не меньше, чем этих возможностей. Я вот например сейчас катаю проект на ASA + PB. Начальные требования к аппаратной части клиента:
сервер+клиент: P2 Celeron 300 mz, 32 RAM
клиент: P2 Celeron 300 mz, 16 RAM
Задачка навороченная, с сложными расчетами и данных кстати не так мало будет. Как Вы думаете, насколько мне бы пришлось увеличить начальные требования к аппаратной части, если бы я заменил ASA на будующий MSSQL Якон или же PB на C# ? Думаю как минимум что то типа:
сервер+клиент: P3 1гц, 256 RAM
клиент: P3 1гц, 128 RAM
Для тиражного ПО, требованием к которому выставляется возможность работы от мелких до крупных клиентов, такая конфигурация не приемлима.

Расчет зп там и делается :) Если в конторке 10 сотрудников и одно рабочее место расчетчика/кадровика, то ASA + PB спокойно потянет. Естественно, если в конторе будет 10000 сотрудников, 6 рабочих мест расчетчиков, 5 рабочих мест табельщиков и 1 рабочее место кадровика, то и требования уже будут к системе другие. Это я и имел ввиду - что в данной связке у меня развязаны руки и ПО будет работать как с мелкими заказчиками, так и с огромными, т.е. получается довольно неплохая маштабируемость.

Serg
У нас просто разные стили проектирования приложений, поэтому и подходы разные и выбор инструментов разный. У меня на СУБД спокойненько считается полный расчет зп (ASA+PB), расчет коммунальных платежей и расчет потребления электроэнергии по схемам подключения промышленных предприятий (обе на MSSQL+Delphi). Никаких претензий по затыкам производительности или нехватки вычислительных мощностей нет - если где что и не так, то это только от кривизны проектирования БД зависит. Во всех случаях клиентская часть наудивления тупа и проста - это просто удобный интерфейс, с различными наворотами удобства пользователя (те же визарды для быстрого ввода сложной информации) и отчеты, данные для которых опять же сначала готовятся на СУБД. При таком подходе для меня, как проектировщика систем, чем инструмент создания клиентской части проще, тем лучше (быстрее катать интерфейсную часть при наличие уже отработанных библиотек и компонентов, плюс более низкие требования к программисту клиентской части, знай себе сиди, DataWindow рисуй и подцепляй уже к готовому интерфейсному решению проекта). Думаю Вы со мной согласитесь, что даже не смотря на полное отсутствие русскоязычной документации любого программиста распостраненных в России средств (Delphi, Access, VFP) гораздо быстрее научить лепить формы в PB, чем в C#, так как PB это инструмент, а .NET - это целая взаимосвязанная платформа, где не зная всего, путем не сделаешь ничего. А при моем подходе проектирования приложения мне вроде как все навороты .NET и не нужны получаются в обычных 2-звенных задачах. Вот нужно будет интернет-приложение сделать, тогда действительно - ASP.NET получается очень даже удобно и красиво.

авторASCRUS, сие:
Раз PBVM под DataWindow.NET ставиться, то это старый обычный ActiveX DataWindow, обернутый интерфейсами .NET

в корне неверно.
А поподробней можно ? Меня очень интересует, чем является DataWindow.NET. А именно - написан ли его движок на чистом C# или же это просто портированный компонент в .NET (тут мне без разницы через чего он портирован: COM, OLE, ActiveX и т.д.). Только мне вот слабо вериться, что они его с нуля переписали на C# - во первых это гигантский обьем работы, старые наработки не применишь, так как в отличие от C++ тут другие концепции и правила программирования, далее печальный опыт производителей сложных компонент (гридов, отчетов, графиков и т.д.), которые перевели все свои наработки на C#, показал, что визуал в C# не самое быстрое, что есть в жизни. GDI+ и сборщик мусора еще те тормоза. Гораздо проще взять старый добрый DW, работающий на PBVM, впихнуть его в .NET, обернуть интерфейсами, дописать на C# редакторы свойств и компонент, чтобы его можно было красиво настраивать в IDE и не задумываться о параллейном сопровождении PB и DW.NET (что и было бы, если бы они увели DW в сторону от PBVM). Единственная получаемая издержка - это то, что в приложениях .NET придеться дополнительно к NetFramework устанавливать PBVM, но думаю это не такая большая цена платы за скорость работы DW.