Re: [firebird-support] Foreign key different field type

[Ann Harrison aharri...@ibphoenix.com [firebird-support]]

On Mon, Jun 19, 2017 at 1:21 PM, Thomas Steinmaurer t...@iblogmanager.com
[firebird-support]  wrote:

> ,
> >
> > Can someone show me example when it is usefull to have different field
> > type in [referenced and referencing keys of a foreign key relationship]?
> >
> >
> > Why this is not forbidden?
>

Why should it be forbidden?  Not everything that's dumb is disallowed.

>
> Perhaps cause the referenced column in table test1 can only store a
> subset (SMALLINT) of the value range of the INTEGER used in test2?
>
> Even if this works at DDL time, I wonder how strict the optimizer then
> is in JOIN statements using an index. Haven't tried.
>

Nor have I tried, but Firebird uses the same key representation for most
numeric
columns, so having mixed sizes of numbers - or different scales -  in a
foreign key
shouldn't matter to the optimizer.  The exception - which may have been
changed -
was the representation of int64. Having a single key format for numbers
makes
it simple to increase the size of columns or change the scale.

Good luck,

Ann

Re: [firebird-support] Why backlash do not raise parser error

[Dimitry Sibiryakov s...@ibphoenix.com [firebird-support]]

20.06.2017 12:42, 'liviusliv...@poczta.onet.pl' liviusliv...@poczta.onet.pl 
[firebird-support] wrote:
> Why backslash does not raise parser :error?

   It does:

> Database: S_TEST, User: SD
> SQL> Select * from rdb$relations\ R
> CON> Inner join rdb$relation_fields rf on rf.rdb$relation_name = 
> r.rdb$relation_name\
> CON> Where
> CON> 1=1;
> Statement failed, SQLSTATE = 42000
> Dynamic SQL Error
> -SQL error code = -104
> -Token unknown - line 1, column 28
> -\

   Most likely your backslash is filtered out by shell or libedit.


-- 
   WBR, SD.






++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu.  Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ 

++


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[firebird-support] Odp: Why backlash do not raise parser error

['liviusliv...@poczta.onet.pl' liviusliv...@poczta.onet.pl [firebird-support]]

Hi,

I see that it is not sql problem only connectivity problem. Delphi Firedac 
remove it before executing.

Regards,
Karol Bieniaszewski

- Reply message -
Od: "liviusliv...@poczta.onet.pl" 
Do: 
Temat: Why backlash do not raise parser error
Data: wt., cze 20, 2017 12:42


Hi,

Why backslash does not raise parser :error? 

E.g.
Select * from rdb$relations\ R 
Inner join rdb$relation_fields rf on rf.rdb$relation_name = 
r.rdb$relation_name\ 
Where
1=1

Try first line only or whole sql.

Interesting that mssql also does not raise exception. It have some reserved 
meaning? 

Regards,
Karol Bieniaszewski

[firebird-support] Why backlash do not raise parser error

['liviusliv...@poczta.onet.pl' liviusliv...@poczta.onet.pl [firebird-support]]

Hi,

Why backslash does not raise parser :error? 

E.g.
Select * from rdb$relations\ R 
Inner join rdb$relation_fields rf on rf.rdb$relation_name = 
r.rdb$relation_name\ 
Where
1=1

Try first line only or whole sql.

Interesting that mssql also does not raise exception. It have some reserved 
meaning? 

Regards,
Karol Bieniaszewski

Re: [firebird-support] Foreign key different field type

[Svein Erling Tysvær setys...@gmail.com [firebird-support]]

Well, I would hope that

create procedure ...
declare variable i2 TYPE OF COLUMN test2.id1;
declare variable i TYPE OF COLUMN test.id;
begin
  i2 = 12345678;
  i = 12345678;
...

would complain about the assignment to i and not i2.

Although I agree with you that it sounds rather useless to allow foreign
keys to be of a type that is a superset, it also sounds rather harmless (if
properly implemented). Does the SQL standard say anything about this?

Set