Yes, the number of times I have caught out by that little oddity.
On 16/10/15 14:29, Alex Peshkoff wrote:
> Which must be present in the end of struct or class
The underlying point is that an sql script parser doesn't have to do a
complete analysis but does have to break up the text into blocks o
On 10/16/2015 04:22 PM, Tony Whyman wrote:
> Except that there is no more reason for a separator after the final PSQL
> END statement than there is in 'C' for a semi-colon after a closing brace.
Which must be present in the end of struct or class :)
--
Except that there is no more reason for a separator after the final PSQL
END statement than there is in 'C' for a semi-colon after a closing brace.
On 16/10/15 14:01, Ivan Přenosil wrote:
> There are actually two separators/terminators - one to be used in scripts
> to separate commands, one to be
On 16/10/2015 10:07, Dimitry Sibiryakov wrote:
> 16.10.2015 15:01, Ivan Přenosil wrote:
>> There are actually two separators/terminators - one to be used in scripts
>> to separate commands, one to be used inside PSQL commands.
>> The whole problem is caused by the fact that somebody chose
>> the sa
16.10.2015 15:01, Ivan Přenosil wrote:
> There are actually two separators/terminators - one to be used in scripts
> to separate commands, one to be used inside PSQL commands.
> The whole problem is caused by the fact that somebody chose
> the same character for both.
> So the solution by Adriano i
From: Adriano dos Santos Fernandes
> It seems you like to complicate things.
>
> Call "isql -term !" and do not use SET TERM at all, just terminate your
> full commands with "!".
There are actually two separators/terminators - one to be used in scripts
to separate commands, one to be used inside
Morning Adriano,
> That may be because non-simple (with
> methods) CREATE TYPE may have
> internal semicolons.
Yes, the methods etc are PL/SQL and so will need the / to cause them to be
actually created.
Cheers,
Norm.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity and
Em 15-10-2015 17:32, Norman Dunbar escreveu:
> Hi Adriano,
>
>> Oracle uses something that I didn't understand exactly, wanting a '/'
>> after some commands. That has no (clear) logic.
>
> A wee bit off topic, hopefully Helen won't mind/notice!
>
> In SQL*Plus each statement is terminated by eit
Hi Dmitry,
> Nevertheless, SQL*Plus has command SET SQLT[ERMINATOR].
Indeed it has, and in roughly 20 years of working with Oracle, I've never used
it, nor seen it used.
Cheers,
Norm.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.---
15.10.2015 22:32, Norman Dunbar wrote:
> No set term is required. These are the default terminators, and effectively,
> for Oracle,
> the only two required.
Nevertheless, SQL*Plus has command SET SQLT[ERMINATOR].
--
WBR, SD.
---
Hi Adriano,
> Oracle uses something that I didn't understand exactly, wanting a '/'
> after some commands. That has no (clear) logic.
A wee bit off topic, hopefully Helen won't mind/notice!
In SQL*Plus each statement is terminated by either a ; or a /. Either one means
"execute now". The / has
On 10/15/2015 2:10 PM, Claudio Valderrama C. wrote:
>> Respectfully disagree. Yes, it complicates isql, but it
>> makes the user's life easier. One bit of complication in
>> isql, thousands of simpler to create triggers and procedures.
> And every change in FB's syntax will have to be mirrored i
I've been struggling with this issue for most of my professional life.
Going into the internal demo version of what eventually became PDP-11
Datatrieve, I required semi-colons as terminators. My technical writer
told me that that sucked, I was free to leave it that way, but the
documentation w
> -Original Message-
> From: Ann Harrison [mailto:aharri...@nimbusdb.com]
> Sent: Jueves, 15 de Octubre de 2015 12:34
>
> > On Oct 15, 2015, at 9:59 AM, Dimitry Sibiryakov
> wrote:
> >
> > 15.10.2015 15:51, marius adrian popa wrote:
> >> In InterBase 7 is changed so procedure and trigg
IMO, need to specify SET TERM before every block causes only irritation and nothing more. More than 50% of all errors in the scripts that I prepare by typing relate to missing of this statement or specifying "^" and ";" in wrong order. Damn it! IBExpert as most well-known IDE (and maybe starting po
On 15/10/2015 13:57, p519446 wrote:
> IMO, need to specify SET TERM before every block causes only
> irritation and nothing more.
>
> More than 50% of all errors in the scripts that I prepare by typing
> relate to missing of this statement or specifying "^" and ";" in wrong
> order. Damn it!
>
ALTER DATABASE BEGIN BACKUP;
Adriano
On 15/10/2015 13:14, Tony Whyman wrote:
> Hmmm, I'm not even sure that "complicates" is even the right word here -
> counting BEGIN/END block nesting is not the most complex of programming
> problems. Several years ago I wrote my own SQL statement parser
15.10.2015 18:14, Tony Whyman wrote:
> counting BEGIN/END block nesting is not the most complex of programming
> problems.
Yes, but current parser operates with plain stream of bytes. Splitting it to
separate
lexical units is a higher level of complexity and, I'm afraid, will slow it
down.
Hmmm, I'm not even sure that "complicates" is even the right word here -
counting BEGIN/END block nesting is not the most complex of programming
problems. Several years ago I wrote my own SQL statement parser (in
Pascal) to automate database upgrades without depending on ISQL being
available. M
> On Oct 15, 2015, at 9:59 AM, Dimitry Sibiryakov wrote:
>
> 15.10.2015 15:51, marius adrian popa wrote:
>> In InterBase 7 is changed so procedure and trigger programming language to
>> no longer
>> require the use of SET TERM
>
> IMHO, this is unnecessary complication of isql's parser. I'd
15.10.2015 15:51, marius adrian popa wrote:
> In InterBase 7 is changed so procedure and trigger programming language to no
> longer
> require the use of SET TERM
IMHO, this is unnecessary complication of isql's parser. I'd prefer to
follow KISS concept.
--
WBR, SD.
In InterBase 7 is changed so procedure and trigger programming language to
no longer require the use of SET TERM
http://edn.embarcadero.com/article/29285
--
Firebird-Devel mailing list, web interface at
https://lists.sourc
22 matches
Mail list logo
