то ли ADO глючит, то ли...

← →
olden (2002-01-22 18:10) [0]

MSSQL> процедура, не возвращающая параметров

CREATE PROCEDURE [dbo].[CreateTaxDoc]
@CurPeriodBegin datetime = "010101",
@TMPTableName nvarchar(255) = NULL,
@PaymentId int = NULL
AS
...

в программе происходит вызов процедуры через TADODataSet

ADOds->CommandType = cmdText;
ADOds->CommandText = "exec CreateTaxDoc "010101", NULL, 5";

// Отмечаем, что команда не возвращает набор данных
ADOds->ExecuteOptions = ADOds->ExecuteOptions << eoExecuteNoRecords;

ADOds->Open();

И вот здесь ругается на несовместимость данных
Хотя в QueryAnalyzer та же команда проходит на УРА

Может с настройками датасэта не то. Но я уже все перебрал вроде

← →
Delirium (2002-01-22 19:06) [1]

А что мешает использовать TADOStoredProc? Или хотя бы CommandType указывай cmdStoredProc.

← →
olden (2002-01-23 14:15) [2]

>А что мешает использовать TADOStoredProc?

объект находится в общем DataModule и желаельно чтобы был универсальным (зачем мне два объекта Query и StoredProc вместо одного DataSet)

>Или хотя бы CommandType указывай cmdStoredProc
Та же история (естественно параметры здесь передаю через Parameters) - ругается

← →
Delirium (2002-01-23 14:22) [3]

Я вообще-то пишу в Delphi (D6), а ты (судя по коду) в Builder-е. По этому однозначно утверждать не могу, но у меня еще ни разу не было проблем с передачей параметров в процедуру через ADO.

← →
olden (2002-01-23 15:30) [4]

← →
olden (2002-01-23 16:21) [5]

я пишу и так и эдак
и на Делфях и на Билдере
дело не в том (какая разница)
дело в несогласии ADODataSet работать как StoredProc в случае если хранимая процедура не возвращает набор данных

а вроде должен бы

← →
Delirium (2002-01-23 16:41) [6]

Ну я так и не понял через TADOStoredProc твоя процедура работает или нет?

← →
olden (2002-01-23 16:46) [7]

да, работает
и через TADOQuery тоже
но почему-то через более универсальный TADODataSet не хотит

← →
Delirium (2002-01-23 16:50) [8]

Ну почему это он более универсальный? И у TADOStoredProc и у TADODataSet - общий предок TCustomADODataSet и раз эти компоненты разделены а не наследуются один от другого значит какая-то разница есть. Надо бы ADODB.PAS изучить, но мне лень :)

← →
olden (2002-01-23 18:38) [9]

насколько я понял они разделены для удобства
а TADODataSet как отдельный компонент в палитре вставлен как раз для таких случаев, когда заведомо неизвестно что именно придется выполнять, процедуру или запрос

← →
kig (2002-01-23 19:29) [10]

Для Вас в данном случае "более универсальным" является TADOQuery, т.к. инкапсулирует работу с адошным как Recordset, так и с Command. Соответственно в него добавлен метод ExecSQL для приведенного примера.

Ну не "умеет" адошный Recordset не возвращать результат.

Теперь по поводу eoExecuteNoRecords.

MSDN:

adExecuteNoRecords (в оригинале)
0x80
Indicates that the command text is a command or stored procedure that does not return rows (for example, a command that only inserts data). If any rows are retrieved, they are discarded and not returned.
adExecuteNoRecords can only be passed as an optional parameter to the Command or Connection Execute method

← →
olden (2002-01-24 12:50) [11]

тогда на кой ляд в палитре присутствует отдельный компонент TADODataSet ?
Я понимаю, что процедуру можно выполнить и через Query, но дляэтого придется конвертировать input-параметры процедуры в строку, чтобы скомпоновать TADOQuery.SQL.
Избыточность прям изо всех щелей...
Нутром чую подвох. Наверное все же TADODataSet можно принудить, вопрос лишь в том - как.

Интересен код TADOQuery
function TADOQuery.ExecSQL: Integer;
begin
InitializeMasterFields(Self);
Command.Execute(FRowsAffected, EmptyParam);
Result := FRowsAffected;
end;

Получается что самый правильный код для выполнения моей процедуры через ADODataSet был бы

var Cnt: integer;
TADODataSet.Command.Execute(Cnt, EmptyParam);

Но Command является protected-свойством TCustomADODataSet
И опять - ну в чем смысл существования TADODataSet ?

← →
Delirium (2002-01-24 12:59) [12]

Лично я его не пользую вообще, мне достаточно:
TADOConnection - для коннекта,
TADOQuery - для всех способов получения информации,
TADOCommand - для изменений,
и TADOStoredProc - для процедур, если по каким-либо причинам TADOQuery не подходит.
А зачем TADODataSet, по моему это лишняя придумка Borland-а.

← →
kig (2002-01-24 15:27) [13]

тогда на кой ляд в палитре присутствует отдельный компонент TADODataSet ? - это Борланду :)))

А вообще (но это мое мнение), пока не требуется данные в морду клиента отображать, проще работать напрямую через
_Recordset
_Command
_Stream
...

← →
Delirium (2002-01-24 16:02) [14]

Тогда уж:
CreateOleObject("ADODB.CONNECTION") CreateOleObject("ADODB.RECORDSET") CreateOleObject("ADODB.STREAM")
и вообще забыть по Borland :)

← →
kig (2002-01-24 16:21) [15]

:))

Я это и имел в виду. А можно из ADO_TLB (или как там она назвается) дергать ф-ции возвращаюшие соответстувущий объект.

2 olden
"Я понимаю, что процедуру можно выполнить и через Query, но для этого придется конвертировать input-параметры процедуры в строку, чтобы скомпоновать TADOQuery.SQL." - я не помню уже, как и можно ли в нем параметризованные запросы юзать. Но если через _Command работать - там все ок. С параметрами.

то ли ADO глючит, то ли... Найти похожие ветки