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
Hello Dmitry,
Thursday, October 15, 2015, 8:55:30 PM, you wrote:
> Snapshots are rebuilt and re-uploaded.
Thanks - downloaded the x64 7z kit and it's OK.
Helen
--
Firebird-Devel mailing list, web interface at
https:/
15.10.2015 10:16, Dmitry Yemanov wrote:
>
>> When can we expect to get snapshots? Currently the Windows snapshots
>> are just the Examples sub-tree or, in the case of the PDB kits, just
>> fbclient and engine12 dlls.
>
> They were OK a fews days back. Maybe the build became broken, I will
> verify
15.10.2015 10:01, Helen Borrie wrote:
>
> When can we expect to get snapshots? Currently the Windows snapshots
> are just the Examples sub-tree or, in the case of the PDB kits, just
> fbclient and engine12 dlls.
They were OK a fews days back. Maybe the build became broken, I will
verify in a few
Hello Dmitry,
Thursday, October 15, 2015, 7:25:53 PM, you wrote:
> Current trunk. It was changed between Beta 2 and RC1.
When can we expect to get snapshots? Currently the Windows snapshots
are just the Examples sub-tree or, in the case of the PDB kits, just
fbclient and engine12 dlls.
Helen
20 matches
Mail list logo