Tim

What is the problem with TEDBScripts and parameters? I just changed the script (I clicked Code Editor to bring it up in the IDE to make editing easier) to use the JOIN syntax now its working. Run the app to test and get told parameter DBPath can't be found here

RecentlyOpened.ParamByName('DBPath').AsString := dm.DB.Database;

I click on the Params property and its there BUT view the form as text and

 object RecentlyOpened: TEDBScript
   DatabaseName = 'Memory'
   SessionName = 'TfRSession'
   Params = <>
   SQL.Strings = (

The only way I can seem to get things to work is to click on the Params property, edit one of them (eg alter value and then delete what I've entered) and do Alt-F-V.

Oh yes - D2006

Roy Lambert

SCRIPT (IN DBPath VARCHAR, IN Schedule INTEGER)
BEGIN
DECLARE SQLCode VARCHAR;
DECLARE ResultCursor SENSITIVE CURSOR WITH RETURN FOR Stmt;

SET SQLCode = 'SELECT
_fkProjects,
_LastAccess,
(IF(_LastAccess IS NOT NULL THEN CAST(CAST(CURRENT_TIMESTAMP - _LastAccess AS INTERVAL DAY) AS INTEGER) ELSE 99999))  AS _LongAgo,
P._Name,
P._Type,
P._fkOrderBook,
IF(P._Status = ''L'' THEN ''Live''
ELSE IF(P._Status = ''D'' THEN ''Dead''
ELSE IF(P._Status = ''H'' THEN ''Hold'' ELSE '''')))AS _Status,
_fkUsers
FROM
mruProjects
JOIN "$Disk"."Projects" P ON _fkProjects = P._ID
WHERE
_fkProjects <> :Schedule
ORDER BY
_LongAgo';

PREPARE Stmt FROM REPLACE(':Schedule' WITH CAST(Schedule AS VARCHAR) IN REPLACE('$Disk' WITH DBPath IN SQLCode));
OPEN ResultCursor;
END

Roy,

<< What is the problem with TEDBScripts and parameters? >>

There is no problem.  Script parameters do not work like dynamic statement
parameters.  You need to make sure that you Prepare the script first, and
then you can assign the parameters.  EDB has to compile the script before it
can detect which parameters are present along with their data type.  If you
want the parameters at design-time, then you need to manually create them to
correspond with the script parameters.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>There is no problem. Script parameters do not work like dynamic statement
>parameters. You need to make sure that you Prepare the script first, and
>then you can assign the parameters. EDB has to compile the script before it
>can detect which parameters are present along with their data type. If you
>want the parameters at design-time, then you need to manually create them to
>correspond with the script parameters.

I think there is a problem. It may be one of my expectations vs what's been written but it is there. If I click on the Params property in the IDE it brings up the parameters and displays them as I would expect. I can see them. I then run the app and am told the first parameter does not exist. Go back to the IDE and click Params and there they are. Its only when I look at the form as text I find they're not there.

Why do I need to prepare the script first. Why can't it generate the parameters as part of its creator or when the sql text is changed?

Roy Lambert

Roy,

<< I think there is a problem. It may be one of my expectations vs what's
been written but it is there. If I click on the Params property in the IDE
it brings up the parameters and displays them as I would expect. I can see
them. I then run the app and am told the first parameter does not exist. Go
back to the IDE and click Params and there they are. Its only when I look at
the form as text I find they're not there. >>

At design-time, the Params property for scripts behaves like stored
procedures - when you click on the Params property the script is prepared so
as to grab the parameter definitions for display in the Params property
editor.  If you don't modify any of the parameter values, then nothing will
be stored in the form.

<< Why do I need to prepare the script first. Why can't it generate the
parameters as part of its creator or when the sql text is changed? >>

It can, it just doesn't right now because the scripts were initially
designed to work like a stored procedure.  I'm trying to let you know why
things are behaving the way they are - nothing more, nothing less.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>It can, it just doesn't right now because the scripts were initially
>designed to work like a stored procedure. I'm trying to let you know why
>things are behaving the way they are - nothing more, nothing less.

OK potential misinterpretation - will it be changed?

Roy Lambert

Roy,

<< OK potential misinterpretation - will it be changed? >>

At some point, yes.   For now, the way to work with the parameters is as I
indicated.

--
Tim Young
Elevate Software
www.elevatesoft.com