Заметки Delphi/Lazarus/Oracle/Postgres программиста
Пошаговое описание того, как в домашних условиях с наименьшими трудозатратами установить и запустить СУБД Oracle (для начала в академических целях). И чем-нибудь к нему подключиться и выполнить простой запрос. Замечу, что можно пойти разными путями, я выбрал, как мне кажется, максимально гибкий и минимально трудоёмкий.
Вот наконец-таки я нашёл время и прошёл тест от Embarcadero, который мне достался в подарок. Честно говоря, я планировал к тесту специально подготовиться, подучить матчасть, почитать ещё раз о нововведениях в новых версиях Delphi, запланировать время, чтобы никто не отвлекал… А получилось всё спонтанно: вокруг дел не в проворот, мозги кипят, и чтобы немного отвлечься, вот и решил пройти, тем более там есть 90-дневный срок с момента активации теста (с момента получения подарка).
Есть в нашей БД такая табличка, которая содержит строки файлов (назовём таблицу FILE_LINES). Табличка используется для импорта данных из вне и последующей обработки их на стороне БД. И есть в этой таблице поле, назовём его TEXT, которое по типу своему текстовое. И сначала оно было VARCHAR2(1024) (ну думалось мне, что 1Кб хватит для текстового поля). Потом оно стало VARCHAR2(4000) (4000 – максимальный размер полей типа VARCHAR2 для Oracle). И, конечно же, настал момент, когда заказчик попросил это поле расширить ещё на чуть-чуть…
Вчера размышлял на тему применимости 3D интерфейсов в бизнес-приложениях. А на размышления меня натолкнул конкурс DelphiFeeds, для участия в котором надо написать что-нибудь с использованием FireMonkey. А FireMonkey – это кросс-платформа + возможность реализации 3D, которую ну очень хочется пощупать (даже больше, чем кросс-платформу).
И вот в поисках идеи, я вдруг решил подумать, а насколько это будет юзабельно: 3D-интерфейс в бизнес-приложениях?
Этот пост является расширенным комментарием к посту Александра Алексеева.
Если Вы практикующий программист Delphi, то наверняка сталкивались с проблемой, когда разные проекты работают с некоторой библиотекой (pas-модуль, unit), но каждое приложение работает со своей версией этой библиотеки. Такое часто бывает, когда приложение ссылается на заголовочные файлы GDI+, Direct X или другие модули, портированные в паскаль из C/C++ (бывает так, что одно приложение использует один “порт”, а другое – альтернативный, и эти версии не совместимы между собой). Редко, но бывает и так, что новая версия какого-нибудь, например, XML-парсера не совместима с предыдущей его версией.
Чаще встречается проблема по-сложнее: одно приложение использует одну версию набора компонент, а другое приложение – следующую версию того же набора компонент, не совместимого с предыдущей версией.
Многие практикующие Delphi-программисты знают, что у стандартного TSplitter’а есть ряд недостатков (т.е. багов, если сказать откровенно). В попытках борьбы с ошибками стандартного TSplitter’а, а также желая “прикрутить” к сплиттеру кнопку (для скрытия/отображения связанной панели), я в своё время перепробовал много компонент (доступных для бесплатного скачивания), но так ни на чём конкретно и не остановился: все варианты были чем-то не тем, что нужно было мне. В итоге я решил написать свой компонент.
Разработчики приложений для работы с базами данных (БД) наверняка не раз сталкивались с некоторыми неудобствами при кодировании. Одно из неудобств – это обращение к полю набора данных (НД) по его имени. Неудобство заключается в том, что если к полю обращаться по имени DataSet['FieldName'], то компилятор никаким образом не может проверить, правильно ли написано 'FieldName' и есть ли это поле в НД. А при спешке, кодер может запросто допустить опечатку в имени поля, и, как следствие, это может привести к ошибке во время исполнения приложения.
Я хочу описать технологию, которая может научить компилятор знать, какие имена в таблице могут быть. Это нужно для того, чтобы возможные опечатки исключить на стадии компиляции. А в качестве бонуса, мы можем увидеть список полей в выпадающем списке CodeInsight после имени таблицы и точки. Ну т.е. в конечном итоге, я получаю возможность прямо в коде писать так: TableName.FieldName := 10; вместо привычного нам TableName['FieldName'].AsInteger := 10;