Клиента можно писать абсолютно на чем угодно. Sybase Anywhere Studio (ASA) может работать через ODBC, ADO, OLEDB, JDBC, ADO.NET и Delphi DBExpress, так что выбор за Вами. Ну а насчет Sybase PowerBuilder (PB) - наверное PB можно увидеть частенько рядом с ASA потому, что это оба замечательные продукты, мощные и удобные. На ASA можно элегантно реализовывать довольно сложные по структуре и логике БД, на PB можно красиво и быстро рисовать клиента, причем аналогов его решений просто нет, наверное издали кое в чем по рисованию форм/отчетов смахивает Access, однако в отличие от него PB полностью поддерживает ООП и серьезную кучу наворотов (например встроенную в язык поддержку прямого вызова SQL операторов, кросс-табы, компоненты для организации перекачки/синхронизации данных, язык выражений для динамического изменения свойств контролсов форм ввода, гридов и отчетов, ну и т.д. и т.п.). Единственный самый существенный недостаток - это абсолютное отсутствие русскоязычной документации (правда сейчас пытаемся это исправить), однако если человек представляет как работает Access, и знаком с концепциями ООП по той же Delphi, то PB долго осваивать не придется.

В принципе от связки продуктов ASA и PB специальных выгод, как например у Delphi+Interbase или MSSQL+Access, нет. ASA замечательно работает с любым клиентским приложением (хоть на Perl), а PB спокойно может работать с любой СУБД, причем приложение на нем не привязывается к провайдеру данных и можно спокойно одно и то же приложение гонять под ODBC, потом OLE DB, а затем через ADO.

В принципе я не так давно перешел с Delphi на PB и сейчас как мне кажется на нем разрабатываю более интересные и простые по реализации интерфейсные решения, чем это делал на Delphi, хотя если брать компоненты сторонних производителей (тот же Quantum Grid), по красивости конечно же PB отстает, хотя в принципе и на нем все получается не топорно. В качестве большой ложки дегтя к PB в качестве горькой приправы выступает не очень устойчивая и удобная IDE, которая любит неожиданно вываливаться и имеет ряд досадных ограничений. Однако ради надежности приложения в рунтайме и богатых возможностей PB можно потерпеть даже не самую удобную и устойчивую IDE, дело того стоит, достаточно посмотреть, с какой скоростью на нем катается интерфейс под крупное ПО и как PB позволяет элементарно создавать платформу для расширения форм и отчетов прямо в рунтайме (например, в Sample лежит демка программы, демонстирующей как элементарно на PB можно создать собственный дизайнер для построения клиентских форм и отчетов, да и InfoMaker, входящий в состав PB и разрешенный к свободному распостранению вместе с ПО, показывает, как можно без кода лихо лепить формы ввода данных и отчеты для внутренних нужд и расширения готового ПО самими пользователями).

P.S. Можно упомянуть в качестве достоинств связки ASA+PB их низкие требования к аппаратной части сервера и клиента, а также их маштабируемость в случае больших обьемов работ: ASA спокойно может работать на многопроцессорных системах с ограниченными только ОС размерами памяти, а PB интегрируется вместе с сервером приложений Sybase EAServer и позволяет разрабатывать эффективные трехзвенные приложения.

авторPowerBuilder - приходится править существующий проект - каждый раз ругаюсь и камлаю....
Ну если существующий проект криво сделан, нет продуманной схемы классов, писалось все в лоб - то тогда согласен, ругаться при любом изменении в проекте можно постоянно и долго. Это кстати еще одна из причин, почему мне нравиться PB - если не хочется потом вот так ругаться при доработке проекта или не нравиться, что вышибает IDE, то есть прекрасный выход - продуманно, правильно и красиво программировать на PB, что отучает начинающих программистов писать в лоб (если конечно им показывать, как все делается правильно). Если же писать без продуманной архитектуры приложения, то вместо проекта получится мусорная свалка кое как связанных между собой частей проекта. В отличие от PB на том же Delphi можно спокойно лепить приложения в лоб и они даже будут работать, хотя при таком подходе по мере разрастания и доработки проекта получится все та же свалка.

White Owl Апологеты любого языка могут сказать "это" про свою любимую систему :)
Абсолютно согласен. Причем если они не только это говорят, но и используют свою любимую систему по назначению, то тогда их можно назвать профессионалами высокого уровня. Меня можно пинать ногами, я буду молча соглашаться и не скажу ни слова против, но лично мое глубокое убеждение, что ни смотря на все глюки, которых предостаточно, PB все равно выгодней для крупных проектов в плане написания клиентских приложений, чем тот же Delphi, Java или C#. Замечу, что в свое время я написАлся этих клиентов на Delphi и Java предостаточно (на C# решил даже пока не связываться, опыт сторонних разработчиков компонент меня убедил, что пока WinForms сыроват).

White Owl Когда контрол попытались убить в базовом классе - весь PB умер.
В принципе по правилам проектирования базовые классы не должны изменяться. Мне в этом плане легче, так как в свое время я работал на Java, где особое внимание приходиться уделять именно проектированию иерархии классов, иначе получится куча мала.

В принципе разговор можно закрывать, аргументы все высказанны, патроны кончились :) Просто я полностью согласен с andy753 и его возмущением по поводу Вашей фразы:
White Owl Чрезвычайно сырой и глюкавый продукт. Единственный плюс - навороченный механизм рисования и отображения результатов запросов. И... и все. Все остальное недоделки и странные глюки.
Такое высказывание по меньшей мере странно и может только означать, что Вы не так много/глубоко работали с PowerBuilder.

авторВсе-все, умолкаю...
:)

Флейм, но все же думаю никто не будет против:
Самое забавное, что я наоборот отказался от этих более удачных решений, на которых сидел порядка 10 лет и набабацал кучу классов и компонент на все случаи жизни. Каждый раз, когда менялся номер Delphi, добавлялись ненужные прибамбасы, тяжелела IDE и получаемый код, добавлялись новые глюки, и из за некоторой смены иерархии VCL мне иногда приходилось кучу всего переделывать, то я так же ругался нехорошими словами. Наверное тут уже дело больше в психологии - долго проработав с продуктом, у которого баги тянуться годами и не исправляются человек в конце концов теряет остатки своего терпения и начинает подумывать о миграции на другой продукт. К сожалению другой продукт не имея казалось бы заветных багов и заманчиво маня, на поверку оказывается таким же багообразным творением, весь фокус обычно состоит в том, что баги у него возникают в другом месте и в другое время, что вполне обьясняется стилем программирования его разработчиков, его архитектурой, принципами работы и историей развития. Если никто не против, то я приведу пример сравнительного анализа, которым я руководствовался, переходя на PB и начиная на нем писать клиентскую часть для нового, довольно крупного проекта. Рассмотрим по порядку, но естественно в кратце и только всего, что касается построения клиентской части.

Delphi (ну и в принципе Borland C Builder)
Достоинства : Удобная во всех отношениях IDE, более менее продуманная иерархия классов VCL, позволяющая строить развитую компонентную модель приложения, разрабатывать сложные визуальные компоненты, интегрировать в IDE собственные дизайнеры, расширяя функциональность и удобство IDE. Очень быстрый и качественный компилятор в 100% нативный код. Довольно неплохая реализация компонент доступа к данным, расширения для построения 3-звенных приложений, работы с офисом, самой ОС и т.д. Так же имеет море библиотек компонент от сторонних разработчиков, причем очень качественных и на все случаи жизни.

Недостатки : Отставание Object Pascal от современных языков ООП. Поддержка наследования в проектах только форм и фраме, работа с обьектами, как указателями памяти, отсутствие сборщика мусора, отсутствие мультикастинга в событийной модели, застой в классах VCL и отсутствие массы необходимых базовых классов (например тех же коллекций), компонентная событийная модель работы, размазывающая бизнес-логику по множеству компонент доступа к данным и их отображения. Сюда же до кучи отсутствие в стандартном комплекте VCL нормальных компонент построения GUI клиента, если конечно не рассматривать клиента как набор примитивных формочек с гридом и навигатором, без всякого намека на дружелюбный и удобный интерфейс. Получается, что нормальный проект на Delphi по любому завязывается на компонентах сторонних производителей, которые стоят деньги, имеют не мало своих глюков и не дают гарантии, что в случае очередного изменения VCL в новой версии Delphi будут корректно или вообще работать и их производители будут их дорабатывать и расширять.

Так же в качестве существенного недостатка я бы указал на отсутствие желание у Borland хоть иногда править баги и ошибки в своих продуктах, а так же расширять VCL. Ну и последний недостаток: фактическая смерть Delphi, которая переходит в стан .NET и теряет свое очарование по той простой причине, что C# и VS.NET IDE все равно будет лучше и на шаг впереди Delphi.NET, подтверждением этому могу привести заявленную спецификацию C# 2.0, в то время как Delphi.NET еле еле по уровню будет дотягивать до C# 1.0 . Мне во всяком случае даже стало обидно, когда я читал, как Borland хитроумно встроил в язык классы-заглушки, обвязывающие классы VCL с классами .NET . Забавно получилось - раньше WINAPI обвязали с помощью VCL, чтобы эффективно строить GUI на базе API Windows, теперь наоборот - с помощью расширения API Windows до ООП уровня .NET в обратную обвязывают VCL, "заботясь" о пользователях, якобы давая им возможность переносить существующие проекты на Delphi.NET . Думаю все согласятся, что это полная чушь, в этом плане MS поступило честнее, порекомендовав пользователям VB6 забить на всякие переносы (все конечно в виде намеков) и начинать катать в VB.NET только новые проекты.

Вердикт : смысла использовать в новых проектах нет, так как нет уверенности в ее будующем развитие, производителя штормит в разные стороны между MS и Linux, язык и библиотеки во многом устаревшие. Писать проекты на ней можно довольно эффективно, однако только при наличие большого опыта работы с ней, иначе Access Violation станет самой популярной ошибкой конечного приложения.

MS Access 2000/XP ADP проекты
Достоинства
Интеграция с MSSQL с помощью ADO, где Access изначально видит всю БД и использует ее метаобьекты как свои собственные. Особо достоинств перечислять не буду, итак они известны: это легкий в освоении инструмент, удобство быстрой визуальной разработки форм и отчетов, довольно неплохая IDE, приличный по возможностям язык VBA, единый во всем офисе и т.д. и т.п.

Недостатки
Интеграция только с MSSQL на фоне того, что ADO и OLEDB, через которые работает ADP, выглядит мягко говоря не красиво. Зачем было резать Access, привязав его только к одной СУБД никому знать не дано, это большой секрет MS. На самом деле я считаю, что в Access все было бы не так плохо, если бы была возможность полноценной работы с ООП, с поддержкой наследования обьектов проекта, возможности создавать собственные визуальные компоненты для повторного использования и т.д. Все это и еще многие другие ограничения (не будем уж все их перечислять) вычеркивает Access из круга инструментов для построения клиентов крупных проектов.

Вердикт
Хороший инструмент для разработки мелкого ПО. Я обычно всем начинающим и дельфийцам рекомендую обязательно познакомиться с Access, причем не ADP, а именно на обычном Jet движке. Это как еще один взгляд на жизнь, пусть не всегда сразу понятный, но как говориться, чтобы хорошо что то знать, надо обязательно хотя бы ознакомиться с другими, возможно противоположными решениями. Это научит ценить, то что есть и понимать, чего нет.

Java
Достоинства
Кросс-платформеность, очень продуманная и правильная архитектура классов и компонент, гарантирующая, что при дальнейшем развитие Java иерархия уже работающих классов меняться не будет, плавное и постепенное развитие платформы с помощью сообщества разработчиков, где фактически по демократическим принципам принимаются решения о том или ином направлении развития Java. Насыщенность стандартных библиотек классов, которые фактически позволяют делать все что душе угодно. Множество различных качественных IDE от бесплатных open-source, до платных, созданных крупными разработчиками ПО (Sun, IBM, Borland и т.д.).

Недостатки
Обычно, если что то продумано и сделано правильно, да еще универсально, значит это страшно тормозит. К Java это применимо в полном обьеме. Не сказать что требования к процессору и памяти слишком уж высокие, однако и низкими их назвать нельзя. Так же огорчают разные "досадные недоработки" в самом языке, хотя вроде заявлена спецификация расширений в языке, которые позволят Java догнать по возможностям маячащий на горизонте C# 2.0 Однако самое досадное, что, чтобы писать клиента на Java необходимо обладать достаточно высокой квалификацией, так как универсальность и правильность Java сплошь обвязана технологиями и интерфейсами, не изучив которых будет сложно добиться чего нибудь стоящего. В качестве очень не маленького недостатка могу еще указать на отсутствие в стандартных библиотеках иерархии классов, позволяющих на визуальном уровне проектировать наборы данных и связывать их с визуальными компонентами, хотя вроде как базовый набор классов для доступа и работы с СУБД есть (JDBC). В итоге каждый поставщик IDE Java вроде бы честно соблюдая стандарт Java в JDBC, в тоже время придумывает свой велосипед - например если сравнить IBM VisualAge for Java, Sun One Studio и Borland JBuilder, то в этом вопросе ничего общего у них не будет, принципы работы с данными БД будут абсолютно разными, без намека на похожесть. В принципе недостатков можно еще много указать, но для меня эти были основополагающими.

Вердикт :
Для клиентского приложения слишком уж требовательный как к аппаратным, так и кадровым ресурсам. Лично я предпочитаю Java в качестве средства разработки open-source и shareware прикладного ПО в виде утилит под СУБД, парсеров, макро-языков и т.д. Собственно говоря там, где и проявляется вся ООП мощь Java и ее библиотек, а также совсем не помешает кроссплатформенность.

.NET
Достоинств и недостатков писать не буду, потому ничего для реальных проектов не писал. Замечу только, что C# красивый язык, сделанный с учетом ошибок и просчетов Java, CLR содержит множество решений для работы, GUI (WinForms) - кажется все таки пока слабенький, ADO.NET довольно сильна, хотя по моему излишне усложнена, IDE без нареканий - все удобно, нормальных компонент для построения клиентов нет, только резанный грид и отчетник сторонних производителей и куча платных готовых компонент сторонних производителей, что в принципе в духе MS. Требования к аппаратной части и уровню программистов не маленькие, как и в случае с Java. Думаю основной контингент пополнения в полку программистов .NET будет прибывать с Delphi и VB6.

Вердикт
Все таки для написания GUI не годиться. На ASP.NET же здорово получается веб-решения делать, здесь .NET действительно перспективный и удобный инструмент.

PowerBuilder
Достоинств и недостатков перечислять не буду, думаю находящиеся в этом топике их и так знают. Замечу только, что если внимательно посмотреть на PB и выше перечисленные продукты, то недостатков у PB конечно же будет не меньше, однако по процентному соотношению между Достоинствами и Недостатками в области клиентостроения у PB перевесят достоинства, в отличие от конкурирующих продуктов: не высокие требования к кодерам клиентской части (типичный пример: сидят себе и DataWindow мышкой рисуют, который потом уже к готовой и продуманной интерфейсной части проекта подключается), не высокие требования к аппаратной части, встроенный и мощный набор необходимых для работы решений, что избавляет от покупки и осваивания ПО сторонних производителей и уверенность в производителе - вроде пока тьфу тьфу Sybase или PB сдавать рынок не собираются, наоборот стараются его расширить. Например, тот же сектор КПК, на котором уже во всю двигается Sybase ASA и Sybase Pocket PowerBuilder.

Уф, все вышесказанное мое личное мнение, сформированное опытом, приобретенным в ходе разработки крупных проектов, а также обучения и натаскивания начинающих программистов. Где то наверное я не прав. Но буду надеятся, что суть моих изыскания я смог Вам передать :)

Pavel
Стянуть триальную версию можно с http://www.sybase.com . Оттуда же можно взять и паки. По остальным вопросам ко мне лучше обратиться на мыло. Как я уже говорил, самое досадное, что нет никаких русскоязычных книг, однако у меня есть 2-е отсканенные книжки, правда по PB более старых версий, но для начального ознакомления вполне подойдет. Могу выслать их диском по почте. Так же скоро анонсируем рассылку по PB, разговоры о ней уже ходят давно, да вот никак со временем пока не хватает, чтобы ее запустить. Постараемся ее сделать для начинающих, чтобы человек все таки знал, в какую сторону в PB ему копать, чтобы не наступать на грабли разности технологий. Плюс на sql.ru еще работает форум по PB, на котором присутствует лучшие русскоязычные специалисты по PB, которые не раз выручали начинающих.

Pavel
Никак не могу ответить на Ваше письмо - Ваш почтовый провайдер не хочет отвечать.

guest
Отладчик терпимый, но только когда его не вышибает :) Никто и не спорит, что по степени удобства и глюкавости IDE у PB не самое его хорошее место. Однако для меня сами концепции PB и его DataWindow перекрывают недостатки его RAD наворотов, лично мне скорость и легкость разработки и сопровождения гораздо важнее удобства IDE. Хотя не спорю, что удобная и красивая среда разработки прибавила бы плюсов к PB и убрала бы лишнюю "ругань" программистов, которые при сохранении обьектов получают снятие PB :)