I am faced with a growing number of SQL queries and scripts.
I have some in external files, some in the SQL property of a
component and others in my source code.

The source code option is inconvenient as it can't easily be copied
between source and the EDB Manager for testing/development. Also it
bloats and obscures the pascal code.

Using the SQL property of dedicated components is unsuitable for all
but a few cases.

Dumping what will become hudreds of .sql files somewhere in the {app}
folder is messy, confusing and ... devising a naming convention ..

So where do the rest of you put them?  In a table?

--

Malcolm,

<So where do the rest of you put them?  In a table?>

Despite the cons you say, I put them in source code. It has some pros:

1. All is in one. When searching (grep) in source, all is there.
2. Most of SQL code is run-time generated. Most of const formating (ex. date and time) is done by pascal functions (see dbisam and edb have
differnt constant date formating). This enforces name and style conventions.

In order to test run-time generated SQL in manager, I use a function to manage every query before run it. Wich certain /parameter passed to
app, this function shows fully built SQL to user in order to edit before launch it or copy/paste if you want. When no /parameter, app excecutes SQL
behind the scenes.

Tiago Ameller wrote:

> Malcolm,
>
> <So where do the rest of you put them?  In a table?>
>
> Despite the cons you say, I put them in source code. It has some
> pros:
>
> 1. All is in one. When searching (grep) in source, all is there.
> 2. Most of SQL code is run-time generated. Most of const formating
> (ex. date and time) is done by pascal functions (see dbisam and edb
> have differnt constant date formating). This enforces name and
> style conventions.
>
> In order to test run-time generated SQL in manager, I use a
> function to manage every query before run it. Wich certain
> /parameter passed to app, this function shows fully built SQL to
> user in order to edit before launch it or copy/paste if you want.
> When no /parameter, app excecutes SQL behind the scenes.

Thanks for that, Tiago.

In DBISAM I added a debug line SomeQuery.SQL.SaveToFile to get at the
SQL.  But I never got round to writing a function to go from SQL to
pascal code.

I have still to convert a lot of lengthy scripts and there is no way
I will write them in pascal first then try to debug them.  It will be
much quicker to do them in the Manager.  I am now asking myself, why
then convert them to pascal instead of using a LoadFromFile or from a
Stream

--