anthony.bydeveldt wrote:

> --- In firebird-support@yahoogroups.com, "anthony.bydeveldt" <anthony.bydeveldt@...> wrote:
>> Well, apparently the backups are created by GBAK.
>>
>> but this is what is happening:
>>
>> C:\Program Files (x86)\Firebird\bin>gbak -c -v -user SYSDBA -password masterkey c:\temp\retdata.bak c:\temp\test.fdb
>> gbak: opened file c:\temp\retdata.bak
>> gbak: cannot open backup file C:\temp\test.fdb
>> gbak: Exiting before completion due to errors
>>
>> In the manual it says that the destination db must not exists, and it doesn't. In addition, why does it refer to the destination path as the backup file?
>>
>> once again, thanks for your help.
>>
> Just 1 more question guys!
>
> Can anyone tell me which SQL standard the ambiguity rule relating to table aliases was introduced?

I have tried looking it up and SQL92 says: (6.3 Table Reference (used as
TR below)):

"Syntax Rules

1) A <correlation name> immediately contained in a <table refer-
ence> TR is exposed by TR. A <table name> immediately contained
in a <table reference> TR is exposed by TR if and only if TR
does not specify a <correlation name>."

and:
"General Rules

1) The <correlation name> or exposed <table name> contained in a
<table reference> defines that <correlation name> or <table
name> to be an identifier of the table identified by the <table
name> or <derived table> of that <table reference>."

In other words: when a correlation name (or: table alias) is used, only
the correlation name is available for reference (as the table name is
not 'exposed' to the rest of the query).

Section 6.4 is about column references, and is about using exposed table
name or correlation name as a qualifier, or using an implicit qualifier
and rules for resolving ambiguity.

I have also looked at a (draft) version of SQL2003 and I think it also
says this, but then in less clear terms (unless you are a mathematician).

> I understand that the rule wasn't enforced until firebird v2, but I wanted to know which SQL standard that was introduced into.
>
> I am planning on getting the developer to change the software based on it not being SQL standard compliant, as we will be using this software into the foreseeable future and we don't want to get stuck on a 2004 version database server.

--
Mark Rotteveel