Is there a way to check out a script just for syntactical errors?

The reason for asking is that as part of transfering an app from DBISAM a final part is an EDBScript doing nasty things to the tables (eg making sure all character fields, with some exceptions, are ANSI_CI). I obviously don't have the tables whilst I'm developing the script. The full conversion takes a couple of hours (lots of data, complex restructuring) and if I make a cockup (say miss a closing ") its not until the end of the conversion run its found.

Roy Lambert

Roy,

<Is there a way to check out a script just for syntactical errors?>

Wellcome to the Migration Club!

I such cases I test migration scripts against a reduced set of every input table. With a copy of the actual, out of date, input database, run some
DELETE FROM ... in order to retain just few records to test them.

Tiago

Tiago


Unfortunately that doesn't work until you've at least made it through once

Roy Lambert

Roy,

<< Is there a way to check out a script just for syntactical errors? >>

I'm not sure what you mean.  If you prepare the script, then it will be
compiled and will give you any errors that exist in the script.  If you're
talking about pre-testing any PREPAREd/EXECUTEd statements in the script,
then you'll simply need to execute them separately to determine that they
work, just as if you had written them for a TEDBQuery.  Pre-validating a
script is just as hard for EDB as it is for you - it would have to have the
same pre-conditions in place in order to properly compile the statement
being prepared.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< Is there a way to check out a script just for syntactical errors? >>
>
>I'm not sure what you mean. If you prepare the script, then it will be
>compiled and will give you any errors that exist in the script. If you're
>talking about pre-testing any PREPAREd/EXECUTEd statements in the script,
>then you'll simply need to execute them separately to determine that they
>work, just as if you had written them for a TEDBQuery. Pre-validating a
>script is just as hard for EDB as it is for you - it would have to have the
>same pre-conditions in place in order to properly compile the statement
>being prepared.

I'm not wanting to test if they work, just find out if I've made some typos. In many circumstances I can't prepare the statement because the tables don't exist yet.

Roy Lambert

Roy Lambert wrote:


> I'm not wanting to test if they work, just find out if I've made some
> typos. In many circumstances I can't prepare the statement because
> the tables don't exist yet.
>

So I guess that would make it pretty hard to do a syntax check ...

--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz
+
Joan and Jeff Cook
The Cooks Oasis
www.cookislandsoasis.com

Roy,

<< I'm not wanting to test if they work, just find out if I've made some
typos. In many circumstances I can't prepare the statement because the
tables don't exist yet. >>

As Jeff stated, that's what makes it impossible for us to check things also.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim / Jeff


Can either of you explain why a syntax check requires that the table exists rather than a name is supplied for a table in the right place?

From http://dictionary.reference.com/browse/syntax

4.
Computers. the grammatical rules and structural patterns governing the ordered use of appropriate words and symbols for issuing commands, writing code, etc., in a particular software application or programming language.


Roy Lambert