KOLOdbc

← →
AlexY © (2006-05-04 10:21) [0]

Delphi5+KOL 2.35. Подключаю KOLOdbc, в программе объявляю переменную типа PODBCDatabase. Компилятор ругается - Undeclared identifier: "PODBCDatabase".

← →
ECM © (2006-05-04 11:06) [1]

А "KOL" в опциях проекта (Conditional Defines) присутствует?

{$IFDEF KOL} PODBCDatabase = ^TODBCDatabase; {$ENDIF}

Этот модуль - модуль "двойного назначения" - его можно использовать (Владимир наверное предпологал использовать) и в VCL-проектах

← →
AlexY © (2006-05-04 11:08) [2]

Да, присутствует.

← →
AlexY © (2006-05-04 11:22) [3]

Вернее KOL_MCK присутствует. Добавил KOL, заработало.
Спасибо.

← →
AlexY © (2006-05-04 15:18) [4]

EXEшник правда великоват - 82k

← →
ECM © (2006-05-04 15:25) [5]

А есть альтернатива где он меньше?
Включите генерацию map-файла в опциях линкера и посмотрите какой модуль занимает память...

← →
parovoZZ © (2006-06-08 18:42) [6]

А как вытащить номер ошибки?

На VCL
ADOConnection.Errors.Get_Item (0).NativeError

← →
parovoZZ © (2006-06-08 19:03) [7]

Что-то у меня не пошло:

new( Q, Create ); TRY Q.SQL.Text := "Select User_ID, Name From Users Where User=root"; Q.Open; while not Q.Eof do begin ShowMessage (Q.SField[ "name" ]); Q.Next; end; Q.Close; FINALLY Q.Free; END;

← →
parovoZZ © (2006-06-08 19:13) [8]

Ой, ёпрст, кавычки забыл поставить.

А что-то не вижу, как параметры поюзать.

← →
Vladimir Kladov (2006-06-08 20:37) [9]

А нету параметров. И не будет. Научитесь без них обходиться, всегда пригодится. Отсутствие поддержки параметрической мути: 1. облегчает размер кода библиотеки, и довольно серьезно 2. лишает меня возможности наделать в более легком коде вдвое большего числа ошибок 3. лишает вас возможности наткнуться на неслабые проблемы при передаче некоторых типов данных через параметры. Например date/time в MS SQL. У меня где-то (помотрите еще на OLE DB, может там) был набор функций типа Date2SQL, Str2SQL - обычно этого хватает. Строкой передаете в кавычках, и все дела.

← →
parovoZZ © (2006-06-08 21:41) [10]

Неееее, без параметров ниЗЗЗяя. Это как на асме без меток. Придётся dll-ку юзать.

← →
Vladimir Kladov (2006-06-09 16:35) [11]

Бездоказательно. Я уже аргументировал добавлю по использованию. Работаю с разными БД, в основном с MS SQL с 2000 года. Параметрами не пользуюсь принципиально. Пробовал вначале. Ошибок было больше. Просто потому, что параметры лучше всего указывать не опосля, а непосредственно в конструкции SQL-запроса. Иначе легко перепутать местами, и считать замучиться можно, когда запрос приходится менять. Никаких преимуществ по скорости параметры не дают, проверял. О проблемах с типами данных говорил уже. Наконец, поддержка параметров в коде компонента усложнит его как минимум вдвое. Можете проверить, попробовать добавить поддержку.

← →
parovoZZ © (2006-06-09 19:14) [12]

Неее, мне до Вас как до неба. Посмотрел исходники...мама рОдная, роди меня обратно.
Скорости может и не добавляют, а вот удобства при написании запросов хоть отбавляй.

← →
parovoZZ © (2006-06-09 20:08) [13]

Что я тут подумал. Если заморачиваться с dll, то появляется куча проблем. В dll хочу запихнуть ADO компоненты (не хочу переписывать запросы - внутренний моральный стержень не позволяет(с) не помню кто). Но тогда про стринг и двоичные данные произвольной длины можно забыть. Надо юзать ShareMem. Нет ли в кол решения даного недоразумения?

← →
ECM © (2006-06-09 20:25) [14]

> Надо юзать ShareMem. Нет ли в кол решения даного недоразумения?

Ну так и "юзай" его. Кто запрещает?

← →
parovoZZ © (2006-06-09 23:44) [15]

Дык, никогда не юзал. Придётся изучать.

← →
Vladimir Kladov (2006-06-10 08:04) [16]

Против параметров есть еще один серьезный аргумент: неудобство автономной отладки запроса. Если текст запроса не содержит параметров, то достаточно сохранить его перед исполнением просто как строковый файл, и можно его отлаживать в том же Query Analyzer"е, оптимизировать, гонять так и сяк. С параметрами (особенно когда их много) процесс усложняется: надо как минимум редактировать весь запрос, прежде чем выполнять.

ADO = sucks. Я не о размерах. Когда я перешел на прямую работу с MS SQL 6.5 через ODBC драйверы, скорость запросов увеличилась, в отдельных случаях - на порядок.

О размерах: какой смысл с маленьким приложением тащить dll на полметра, мучиться с вынесением в dll части кода. Но это ваше решение.

← →
ECM © (2006-06-10 13:01) [17]

> parovoZZ © (09.06.06 23:44) [15]
> Дык, никогда не юзал. Придётся изучать.

Не придётся... :)) Это просто специальная версия диспетчера памяти.( Сам диспетчер находится в borlndmm.dll) Он позволяет пользоваться одним и тем же диспетчером как в приложении так и в длл. Т.е. можно смело выделять память например в приложении - а в длл её освобождать. (В противном случае у приложения и длл будет своя копия диспетчера и неизбежны падения).
Специального ничего делать не надо - просто поставьте ShareMem в uses и в приложении и в длл-ке и всё.
:)

← →
thaddy (2006-06-10 13:24) [18]

Or use FastMM4. Is about 10K ballast, but less than sharemem.dll.
If both the Dll and the executable are compiled with the proper fastmm4 flag, there is no need for sharemem and your appication becomes a lot faster and more reliable. Especially in the field of databases.

← →
ECM © (2006-06-10 13:26) [19]

> sharemem.dll.

??
:))

← →
Антибайт (2006-06-11 00:54) [20]

Ну ладно, буду ломать свой внутренний стержень

← →
thaddy (2006-06-11 12:43) [21]

2 ECM: borlndmm.dll ofcourse :))

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

Посмотрел исходники - есть какой-то класс EODBC, который создаёт что-то своё. Просит ErrCode : SmallInt. Теперь вопрос - где его взять? EODBC.ErrorCode? Будем попробовать.

ЗЫ на ADO проще ADOConnection.Errors.Get_Item (0).NativeError - вот и ошибка. Делай с ней всё, что хочешь.

> Теперь вопрос - где его взять? EODBC.ErrorCode?

:))
А может прежде чем задавать глупые вопросы хоть немного подумать?
Да тут он и лежит
except on E: EODBC do
E.ErrorCode - вот и ошибка. Делай с ней всё, что хочешь (c)

{
KOLOdbc.pas (c) by Vladimir Kladov, 2005
11.03.2005, 27.12.2005

Классы:
EODBC - класс для обработки ошибок ODBC
...
type
EODBC = class( Exception )
protected
constructor CreateError( HandleType: SmallInt; fHandle: THandle; ErrCode: SmallInt; const Msg
: String );
public
constructor CreateEnvError( fHandle: THandle; ErrCode: SmallInt; const Msg: String );
constructor CreateConnError( fHandle: THandle; ErrCode: SmallInt; const Msg: String );
constructor CreateStmtError( fHandle: THandle; ErrCode: SmallInt; const Msg: String );
end;

далее по тексту везде раскиданы
raise EODBC.CreateXXXXX;

почитайте про обработку исключений в Delphi - может полегчает

Вот так

try DB.DSNConnect (); except on E: EODBC do E.ErrorCode MyFunc (...., E); end;
?

on E: EODBC do MyFunc (...., E.ErrorCode);

Хм, дохлый номер. А как мне в except что-то ещё засунуть? Вариант

except
on E : EODBC do
MessageDlg (E.Message, mtWarning, [mbOk], 0);
DB.Disconnect;
exit;
end;

не проходит.

Исчо :)

SQL := "Select User_ID, Name From Users Where User="" + edLogin + """; try Query.SQL.Text := SQL; Query.Open; User_ID := Query.IField[ "User_ID" ];// <-- Выпадает в ошибку Query.Close; except

На ADO всё прекрасно.

Дико извиняюсь, но это опять Я.
Ошибка такая: неизвестный тип данных поля User_ID.

Ещё чего.
E.ErrorCode всегда возвращает 0. На ADO я различал: неправильный логин или пароль, нет связи с сервером удалённой базы данных, связь потеряна, отмена вставки триггером ну и т.д. А тот текст, содержащийся в E.Message, юзеру не нужен.
Почему-то через ConnectionString не могу подключиься. ХЗ. На ADO всё замечательно.

KOLOdbc Найти похожие ветки