У нас в организации сетевой комплекс программ, написанный на Clipper 5.02. Накоплены базы о клиентах за 15 лет. Терять их не хочется. Периодически приходится изменять программы, а иногда дописывать новые для этого комплекса. Используется около 150 баз и справочников. Естественно, что многие из них - общие для всех программ.
Как перейти на новый язык программирования, чтобы не переписывать все программы?
Начать хотя бы с того, чтобы новые программы для этого комплекса писать на новом языке...
Какой язык выбрать?
Есть ли такие, которые поддерживают работу с dbf-файлами в старой DOS-кодировке?

Учавствовал в решении подобной задачи. На какую систему вы бы не переходили переписать программы придется. Оставаться на dbf файлах нет смысла. В данном случае выберете СУБД (MS SQL Server, mySQL и п.р.), преобразование данных не будет сложной проблемой. В противном случае смысла переходить на другую платформу нет, вы не получите новых возможностей, а обретете только сложности с потдержкой в новой среде устаревшей технологии. В качестве среды разработки был использован MS Access. В Вашем случае будет лучше переходить на то, что знаете. Если же все равно, что учить, то на мой взгляд оптимальный выбор это платформа .NET (C# или любой другой язык).

Жалко, конечно, что нет других вариантов.
Дело в том, что я один программист в этой организации. А комплекс довольно серьезный. Боюсь, что буду переписывать его до пенсии.

Зачем?

Программы работают отлично, не тормозят, однако появилась необходимость в бланки вставлять изображения, хранить изображения в БД, чего к сожалению я не могу реализовать

Правильно боитесь, переписать одному человеку более менее серьезный комплекс в разумные сроки не реально. Усугубляется все тем, что комплекс не покрыт тестами и организовать нормальный тест процесс не получится-баги (причем много)будете ловить уже после ввода в эксплуатацию со всеми вытекающими из этого последствиями, потому как начальству нужен результат, а не использование новейших технологий. С другой стороны писать новый модули на клипере не есть хорошо и не столько потому, что технология в стадии стагнации, сколько потому что это плохо для вашей квалификации и будующего, как программиста. В остатке мы получаем необходимость создания гетерогенного комплекса: старые модули не трогаем, новые пишем на чем то новом. В плюсе: ничего не поломаем, не так сильно пугаем пользователей(одно дело привыкать к новому гую одного модуля, другое дело - ко всей новой системе), полезно для квалификации. В минусе: косяки с интеграцией. Что бы минимизировать эти косяки берем яву, технология одна из самый перспективных и что самое главное ей уже лет так 10-15. За это время с ней интегрировали все, что только можно, так что найти готовое решение или хотя опыт будет достачтоно легко. А если интеграция будет заключатся только в поднимании данных из dbf то задача вообще тривиальная. А если выставить для доступа к данным Hibernate то можно будет вообще абстрагироваться от конкретной бд и потом потиху мигрировать с dbf.

Почему именно в БД?


Порочно это. Так у господина - , а теперь ява да еще + Hibernate с абстракцией, - вот уж клиенты точно не обрадуются.

Можно попытаться запихивать изображения в поля типа MEMO, однако такие данные хранятся в отдельных файлах, поэтому фактически нет разницы - хранить ли кучу отдельных файлов или кучу отдельных фото. Все равно придется писать обработку руками.

В сети мне попадались языки типа Alaska Xbase++ (здесь что-то про него ]]>http://www.hotsoft.ru/ALASKA/index.htm)]]> , которые якобы имеют клипперовский синтаксис и умеют то, чего не умеет клиппер.

У нас еще около 40 рабочих мест - PentiumI. Компьютеры по-тиху меняем... Но они "вылетают" не так быстро, как хотелось бы. Windows95 соответственно. Совместимо ли это с Явой? И что будет со скоростью?
Всего около 70 компьютеров работают с 17 АРМами.




А как запихивать в мемо? Можно ли jpeg или bmp? Был один вариант - в одном месте программы шаблон вставляется не из емо, а из тхт-файла. С трудом, но нарисовали то, что надо. Но при выводе на печать (естественно, принтер лпт, матричный ) - изображение вытягивается по вертикали. Очень сильно.



По поводу Alaska Xbase++ - спасибо, почитаю.

будет быстрее чем на клипере, если уж вам так нравятся не аргументированные заявления. и вообще бан нуна за провокацию=)



Совместимо, но только с J2SE 3.1.1_xx, что не есть гуд. Релиз очень древний и естественно многих фенечек современной явы в нем нет и многие фреймворки которые стали де-факто стандартом использовать не получится. Скорость будет приемлемой, полагаю сравнимой с кипером. Но я предлагаю другой вариант: попробовать создать систему с тонким клиентом, в данном случае, бравзеров. Это решит проблему дохлых клиентских машин и даст возможность использовать современные технологии. Плюс это сейчас модно=) и такой опыт будет востребован на рынке труда.

Лучше всегда то, что знаешь.

Не понимаю зачем искать что-то другое, если необходимо просто напросто использовать картинки. Их можно вообще хранить в как файлы, а в базе имена и относительный путь. Зачем изображения куда-то записывать? А вот печатать действительно проблема.

Как я понимаю, тонкий клиент - это система сервер-клиент. А у нас файл-сервер. Как же тогда можно будет часть программ оставить на клиппер, а остальные писать на ява? Или я не совсем в этом разбираюсь....

Что тут пояснять, это как аксиома И, простите, про провокацию чего речь? о_О

MarPush
Ну поясните же почему карттинки надо именно в БД запихивать? уже 3 человека спрашивают. Или это ваш т.с. аргумент к "переходу"?

Это медучереждение. Сейчас появилось множество аппаратов, дающее изображение в цифровом формате. А у нас электронная история болезни. Организованная на клипере. Это раз.
Во вторых, во многих документах, теперь требуется не только описать патологию больного, но и отметить на схеме того или иного органа - где же эта потология конкретно находится.
Т.е. раньше просто заключение (например, УЗИ) выбиралось из шаблона (справочник) и сохранялось в мемо поле соотвентственно для каждого пациента. Теперь же этом шаблоне должно быть и схематичное изображение органа, на котором врач собственноручно должен что-нибудь дорисовать и поставить свою подпись.
Понятно, что можно распечатать фотографию с аппарата, но есть официальные бланки с картинками для заполнения, которые меня ну очень просят вставить в шаблоны.



Хотя главный аргумент к переходу - это желание начать писать на другом языке, так как справедливо было замечено, технология Clipper находится в стадии стагнации...

ты предлагаешь человеку всю жизнь разрабатывать на клипере? ничего не имею против клипера, но мне кажется , что технология не развивается и сфера ее применения сужается. да, он может стать редким ценным специалистом и зашибать мега бабло, а может так статься, что его уникальные знания никому и нужны то не будут. что тогда?! а иметь опыт в востребованных на рынке технологиях всегда полезно, хотя бы для расширения кругозора и для того, что разговаривать о зп с начальством на равных:"вы тут на коипере сидите,а я возьму и уйду на яву(дотнет, qt, руби), найдете мне замену?"=).

в общем случае доступ к файловой системе не транзакционен. а это может аукнуться. хотя в файл-серверных бд вроде бы с этим тоже не ахти.

скорее трехзвенка, но это не суть важно. ключевое отличие всеравно одно, в твоем случае вся бизнес логика отрабатывает на клиенте, в случае трехзвенки бизнес логика выносится на удаленный сервер. Возможная сложность, которая сходу видится, это обеспечение транзакционности и целостности данных, так как в случае с файл-серверными базами данных с этим все достаточно плохо и обспечивается распределенно на клиентах. Этот вопрос тебе придется изучить самостоятельно, так как у меня опыта работы с файл-серверными базами данных маловато и архитектуры твоего комплека я не не знаю.

Знаете, а на самом деле все равно тут без вариантов - ну, никуда не денешься - хочешь или нет, но придется переводить систему на другие "рельсы". Надобность в изображениях и качественной печати- это только начало, а ведь дальше еще хуже будет: могут, и скорее всего будут, появляться другие потребности, которые невозможно решить в рамках текущей системы Clipper + Dbf.

Когда-то я тоже сталкивался с подобной ситуацией. В моем случае люди переходили на Delphi и Firebird. Решение не из худших по нескольким причинам: во-первых (не смеяться ), у нас любят "рабский" труд студентов, а они Delphi знают как правило; во-вторых, все это отлично и на Windows 95 будет работать - то есть это эдакий бюджетный вариант.
В другом же случае люди были привязаны к формату dbf условиями проекта. Они решили переписать клипперную часть на Delphi (для работы с dbf использовали компоненты Halcyon).
Разумеется, о возможном качестве реализации я не говорю... Да и потом, когда работа дойдет до середины, окажется, что Минздрав заключил договор с каким-нибудь "EPAM" и всем будут ставить одно и тоже по Республике?

тфу тфу тфу (через левое)

MarPush, я в большом шоке. У вас огромный проект. Проектище можно сказать. И вы один программист? Помойму начальство настоящие экстремалы.

К делу. Рекомендация одна. Хотите простоты работы с картинками и прочего, то дорога на другую платформу. Другие платформы - это .NET (можно писать и на Java и на VB - предлагаю обратить внимание, т.к. чуть-чуть похож на Cliper), Java, Borland Builder C++ / Delphi (.NET от Borland), MFC. Что я еще забыл?

Что вы вибирете не имеет значения. Нет ни плохой ни хорошей платформы. Есть одно но! Ни одна из них не потдерживает печати. Для этого понадобится сторонняя библиотека или ручная работа. Сторонние это: Cristal Reports (в последную Visual Studo встроена), FastReports (и прочее) для Borland, ручками формировать rtf, и еще куча решений.

Мне понравилось предложение Kmet - новое на новом. Старое глаз не режет.

Сравнение.
Сейчас очень популярны .NET и Java. Почему? Очень быстро можно клепать программы. А что еще главное можно клепать ОЧЕНЬ большие программы - трех звенки. Недостатком у них является их достоиснство - сборщик мусора. На этом все. Используюя их можно получить довольно гибкий язык для всяких извращений и полностью сосредоточится на том, чтобы писать клиентский приложения. Задача проста как божий день - достать из базы, показать, чуть-чуть обработать, положить в базу.

На мой взгляд у Java, перед .NET есть один недостаток - разнообразие. Если не знаешь, то выбрать среду разработки это сущий гемор. Одна краше другой. Microsoft предлагает среду Visual Studio и полную интреграцию со всеми своими продуктами (читай MS SQL Server). Прикрутить mySQL сервер, так же как и MS SQL Server прикручивается требует стучание в огромный программистско/админский бубен или выкладывания денег за готовые решения (да есть такие).

С++ - чесслово UI писать геморно - указатели, память, типы - кому это нужно? Зато работает быстро :-). В этом вся и прелесть. Нужен полный контроль и производительность, то сюда.
Delphi - субъективаня не переносимость. var, begin, end меня убивают. А так то же, что и С++ (любители холивар идут лесом).

Да, учится придется. Желательно курсы. Книжка не поможет. А еще лучше добавить готового специалиста в помощь. Готовые решения они облегчают жизнь и избавляют сон от программистких кошмаров.

Развиваться не нужно, тогда остается Cliper. Он свое дело знает. Писал когда-то на нем.

MarPush, ой, совсем забыл про такую веселую систему как Visual FoxPro. Они с Cliper одной крови - концепция та же. Зато позволяет больше, хоть COM Server пиши. Dbf любит, как сладкие пироженые. Печать встроеная есть. А сколько бухгалетерских програмок на них написано, просто не счесть. В платформе мудрости и страх команд по больше чем в любой новомодной технологии. И все проверены временем. Стоит присмотреться. Получите и распишитесь, ничего больше для счастливой жини не нужно. Почему сейчас не так популярна... А черт его знает.

Чтобы с ней разобраться подойдет и книжка.

Удачи.

MarPush
Хотел написать, но уже опередили. Почему бы Вам не попробовать Visual FoxPro-9? ( FoxPro - DOS). Действительно вопрос - почему она
сейчас не так популярна, как в начале 90-х. Ответ - слабая поддержка О.О.П. Зато старое доброе проц. программирование осталось.
Для практика - то что надо. Есть поля General(фото). Печать - без проблем. Скучновата, но Вам же - не развлекаться. Для развлечения
могу порекомендовать схему: Linux - C++ - Qt4. Но это в перерывах между работой, если время останется.
Порекомендовал бы 2 книги:
О.В. Бартеньев "Microsoft Visual FoxPro" (Справочник - операторы, функции).
Т.В. Мусина, В.А. Пушенко "Visual FoxPro 7.0" !!! - практич. руководство . На стр. 278 - как раз печать фото на формах.

Удачи. Почему-то думаю, что справитесь и один.

Господи, это же из фильма ужасов, когда упаковку с индексацией базы данных делать прийдется. А больные чего, не выздоравливают как мухи? (это по Гоголю) Мне казалось, что все рабочие архивы хранятся 5 лет, а остальное надо паковать и на полку (можно и с клипером вместе). С таким желанием хранить все записи в одном месте только SQL технология выдерживать будет. По моему надо сначала пересмотреть подход к хранению данных вообще.

Тут каждый советует свою любимую среду разработки, но у Вас не полное знания Клипера - не знаем как в МЕМО заталкивать бинарные данные. Надо бы сначала старый вариант полностью изучить, а потом уже выбирать альтернативу. Только без обид - мы все чего-то не знаем.

Кстати, по собственному опыту работы с Клипером, рекомендую заводить поле с именем графического файла, а не засовывать его в МЕМО. Это сократит код программы, а вывод графики на принтер можно будет осуществлять при помощи сторонней программы.

Соглашусь с большинством, говорящих тут, что писать комплекс программ в одиночку не благодарное дело - трудно осилить, да и не оценят. Еще и здоровье надо иметь в запасе не хилое. Но если уж встал вопрос и надо решать, то лично моя рекомендация не привязываться к какому то из языков программирования или среде разработке, а пойти несколько иным путем: Так как база на файлсервере, то оптимальным будет использовать доступ к ней через ODBS.

Первое преимущество, это возможность работы со старым DBASE-4 в интерпретации Clipper 5, а при случае конвертнуть ее в любой другой формат по потребности, и просто переназначить в программе источник, включая и обращения к SQL серверам, так как все запросы ODBS конвертирует именно в SQL запросы. В этом случае код программы не нужно будет менять - все запросы останутся старыми. Дополнительно, тот же драйвер SQL в ODBS обращается к серверу по сети, что в последствии даст возможность отказаться и от файлсервера.

Второе преимущество, это смена языка программирования и среды разработки в любое время и на свое усмотрение. Практически все сегодняшние языки программирования поддерживают обращение к ODBS в своих таблицах баз данных. При чем, некоторые программные комплексы разработки не совсем корректно обрабатываю DBF созданный именно Клипером, а через драйвера ODBS эта проблема исчезает.

К тому же, обращение к базе данных через сторонний драйвер ODBS не только должен сократить код самой программы, но и время на разработку. Останется только выбрать среду разработки близку сердцу и уму (по скорости и удобству, лучше ориентироваться на среду разработки, а не на язык программирования), а если в процессе работы что-то не устроит, то спокойно переключиться на другую.

человек явно на поддержке, такое положение вещей обычное дело.


Печать и репортинг вещи во многом ортогональные, не путайте человека. Но и для того и для того решений масса.


Это плюс. Что не выберал - не прогадаешь. Качество основых ИДЕ весьма высокое и можно выбрать лучшее для твоей специфики. ИДЕА так вообще, имхо, эталон, хотя сам предпочитаю клипсу. По поводу "зоопарк фреймворков(ява) вс генеральная линия партии(дотнет)" уже был флем на этом форуме, поиск в помощь.

Пробовали Qt, HtmlLayout?!

Что это?!

Клипер на фокспро, имхо, это шило на мыло


ODBC?!

Если нужно абстрогироваться от источника данных - ODBC далеко не лучший выбор.

Спасибо всем, пока взялась читать про ODBC

Эээ ... там читать то, нечего.

Ну да, пардон