Cross-database foreign key references are not supported. Workaround?

When I try to create a cross-database foreign key constraint, I get
"Cross-database foreign key references are not supported"
The cause of the message is, of course, obvious. However, I would still like
to have a constraint based on rows in a table of another database (running
in the same instance).
Is there any way round this, or am I trying to do something unreasonable? If
it's not possible, what would others normally do in this situation?
TIA
CharlesGiven that I don't fully understand your scenario, or what set of
requirements is driving the separation of the data in the first place, if
you really want to enforce the relationship, then keep both tables in the
same database, and then create a view in the other database where you think
you need a "copy" of the data.
A
"Charles Law" <blank@.nowhere.com> wrote in message
news:e%235ZS3UUIHA.4280@.TK2MSFTNGP06.phx.gbl...
> When I try to create a cross-database foreign key constraint, I get
> "Cross-database foreign key references are not supported"
> The cause of the message is, of course, obvious. However, I would still
> like to have a constraint based on rows in a table of another database
> (running in the same instance).
> Is there any way round this, or am I trying to do something unreasonable?
> If it's not possible, what would others normally do in this situation?
> TIA
> Charles
>|||>> Is there any way round this, or am I trying to do something unreasonable?
>> If it's not possible, what would others normally do in this situation?
You are not trying to do anything unreasonable. In fact, it is a very common
issue. Since DRI between databases are not supported, people usually use
triggers (a way of procedural referential integrity) to get the job done.
--
Anith|||Charles,
By definition, constraints only work within a database. The only mechanism
that I have used for cross-database constraints is triggers. (And only
occasionally.)
RLF
"Charles Law" <blank@.nowhere.com> wrote in message
news:e%235ZS3UUIHA.4280@.TK2MSFTNGP06.phx.gbl...
> When I try to create a cross-database foreign key constraint, I get
> "Cross-database foreign key references are not supported"
> The cause of the message is, of course, obvious. However, I would still
> like to have a constraint based on rows in a table of another database
> (running in the same instance).
> Is there any way round this, or am I trying to do something unreasonable?
> If it's not possible, what would others normally do in this situation?
> TIA
> Charles
>|||Hi Aaron
Thanks for the quick response. We have two databases: one containing static
(look-up) data, and one containing transient data that gets updated on a
regular basis. There are tables in the latter database that have columns
requiring a corresponding record in a static table (in the other database).
That is why I have been trying to create a cross-database foreign key
constraint. The databases are separate since the look-up data will change
from customer to customer, and it is more convenient to be able to 'plug in'
a new set of static data if it is in a separate database.
Charles
"Aaron Bertrand [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:epNsk9UUIHA.4440@.TK2MSFTNGP06.phx.gbl...
> Given that I don't fully understand your scenario, or what set of
> requirements is driving the separation of the data in the first place, if
> you really want to enforce the relationship, then keep both tables in the
> same database, and then create a view in the other database where you
> think you need a "copy" of the data.
> A
>
> "Charles Law" <blank@.nowhere.com> wrote in message
> news:e%235ZS3UUIHA.4280@.TK2MSFTNGP06.phx.gbl...
>> When I try to create a cross-database foreign key constraint, I get
>> "Cross-database foreign key references are not supported"
>> The cause of the message is, of course, obvious. However, I would still
>> like to have a constraint based on rows in a table of another database
>> (running in the same instance).
>> Is there any way round this, or am I trying to do something unreasonable?
>> If it's not possible, what would others normally do in this situation?
>> TIA
>> Charles
>>
>|||Hi Russell
Thanks for the reply. I see that Anith is suggesting much the same thing as
well, so with two votes I will look at using triggers.
Cheers.
Charles
"Russell Fields" <russellfields@.nomail.com> wrote in message
news:%23IfhS%23UUIHA.5516@.TK2MSFTNGP02.phx.gbl...
> Charles,
> By definition, constraints only work within a database. The only
> mechanism that I have used for cross-database constraints is triggers.
> (And only occasionally.)
> RLF
> "Charles Law" <blank@.nowhere.com> wrote in message
> news:e%235ZS3UUIHA.4280@.TK2MSFTNGP06.phx.gbl...
>> When I try to create a cross-database foreign key constraint, I get
>> "Cross-database foreign key references are not supported"
>> The cause of the message is, of course, obvious. However, I would still
>> like to have a constraint based on rows in a table of another database
>> (running in the same instance).
>> Is there any way round this, or am I trying to do something unreasonable?
>> If it's not possible, what would others normally do in this situation?
>> TIA
>> Charles
>>
>|||Hi Anith
Thanks for the quick reply. As I replied to Russell, with your and his vote,
it looks like I will be looking at triggers.
Cheers.
Charles
"Anith Sen" <anith@.bizdatasolutions.com> wrote in message
news:uyA15%23UUIHA.5404@.TK2MSFTNGP03.phx.gbl...
>> Is there any way round this, or am I trying to do something
>> unreasonable? If it's not possible, what would others normally do in
>> this situation?
> You are not trying to do anything unreasonable. In fact, it is a very
> common issue. Since DRI between databases are not supported, people
> usually use triggers (a way of procedural referential integrity) to get
> the job done.
> --
> Anith
>|||On Jan 7, 10:53 am, "Charles Law" <bl...@.nowhere.com> wrote:
> When I try to create a cross-database foreign key constraint, I get
> "Cross-database foreign key references are not supported"
> The cause of the message is, of course, obvious. However, I would still like
> to have a constraint based on rows in a table of another database (running
> in the same instance).
> Is there any way round this, or am I trying to do something unreasonable? If
> it's not possible, what would others normally do in this situation?
> TIA
> Charles
Charles,
I hope you realize that whatever solution you choose, it might not be
fully watertight. If you ever need to restore one of your databases
from a backup, that may violate your integrity - I don't know a fully
safe solution. Also be aware that sometimes trigger do not fire.|||Hi
There is also the option of using a function in the constraint.
John
"Charles Law" wrote:
> Hi Anith
> Thanks for the quick reply. As I replied to Russell, with your and his vote,
> it looks like I will be looking at triggers.
> Cheers.
> Charles
>
> "Anith Sen" <anith@.bizdatasolutions.com> wrote in message
> news:uyA15%23UUIHA.5404@.TK2MSFTNGP03.phx.gbl...
> >> Is there any way round this, or am I trying to do something
> >> unreasonable? If it's not possible, what would others normally do in
> >> this situation?
> >
> > You are not trying to do anything unreasonable. In fact, it is a very
> > common issue. Since DRI between databases are not supported, people
> > usually use triggers (a way of procedural referential integrity) to get
> > the job done.
> >
> > --
> > Anith
> >
>
>|||Hi John
Any idea how performance compares between use of FK constraint (if it were
available), trigger and function?
Charles
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:7243FE54-4405-4EC3-80A6-F9ABFB98117E@.microsoft.com...
> Hi
> There is also the option of using a function in the constraint.
> John
> "Charles Law" wrote:
>> Hi Anith
>> Thanks for the quick reply. As I replied to Russell, with your and his
>> vote,
>> it looks like I will be looking at triggers.
>> Cheers.
>> Charles
>>
>> "Anith Sen" <anith@.bizdatasolutions.com> wrote in message
>> news:uyA15%23UUIHA.5404@.TK2MSFTNGP03.phx.gbl...
>> >> Is there any way round this, or am I trying to do something
>> >> unreasonable? If it's not possible, what would others normally do in
>> >> this situation?
>> >
>> > You are not trying to do anything unreasonable. In fact, it is a very
>> > common issue. Since DRI between databases are not supported, people
>> > usually use triggers (a way of procedural referential integrity) to get
>> > the job done.
>> >
>> > --
>> > Anith
>> >
>>|||"Charles Law" <blank@.nowhere.com> wrote in message
news:e9P4QCVUIHA.5980@.TK2MSFTNGP04.phx.gbl...
> Hi Aaron
> The databases are separate since the look-up data will change from
> customer to customer, and it is more convenient to be able to 'plug in' a
> new set of static data if it is in a separate database.
>
I think your question demonstrates exactly the opposite. It is much LESS
convenient to put the static data in a separate database precisely because
that data is very likely to be referenced by a foreign key.
--
David Portas|||> I hope you realize that whatever solution you choose, it might not be
> fully watertight. If you ever need to restore one of your databases
> from a backup, that may violate your integrity - I don't know a fully
> safe solution
Good point.
> Also be aware that sometimes trigger do not fire.
That would be worrying if it were random. Do you mean that they sometimes
don't fire for no apparent reason?
Charles
"Alex Kuznetsov" <alkuzo@.gmail.com> wrote in message
news:6d8fa87b-9204-4858-a727-7b8c40d625e0@.1g2000hsl.googlegroups.com...
> On Jan 7, 10:53 am, "Charles Law" <bl...@.nowhere.com> wrote:
>> When I try to create a cross-database foreign key constraint, I get
>> "Cross-database foreign key references are not supported"
>> The cause of the message is, of course, obvious. However, I would still
>> like
>> to have a constraint based on rows in a table of another database
>> (running
>> in the same instance).
>> Is there any way round this, or am I trying to do something unreasonable?
>> If
>> it's not possible, what would others normally do in this situation?
>> TIA
>> Charles
> Charles,
> I hope you realize that whatever solution you choose, it might not be
> fully watertight. If you ever need to restore one of your databases
> from a backup, that may violate your integrity - I don't know a fully
> safe solution. Also be aware that sometimes trigger do not fire.|||Hi David
I can't argue with your logic there.
I'll have to give this some more careful thought. Perhaps I am creating more
problems than I solve by separating the static data from the rest.
Charles
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:uXD2f9VUIHA.5360@.TK2MSFTNGP03.phx.gbl...
> "Charles Law" <blank@.nowhere.com> wrote in message
> news:e9P4QCVUIHA.5980@.TK2MSFTNGP04.phx.gbl...
>> Hi Aaron
>> The databases are separate since the look-up data will change from
>> customer to customer, and it is more convenient to be able to 'plug in' a
>> new set of static data if it is in a separate database.
> I think your question demonstrates exactly the opposite. It is much LESS
> convenient to put the static data in a separate database precisely because
> that data is very likely to be referenced by a foreign key.
> --
> David Portas
>|||On Jan 7, 1:06 pm, "Charles Law" <bl...@.nowhere.com> wrote:
> > I hope you realize that whatever solution you choose, it might not be
> > fully watertight. If you ever need to restore one of your databases
> > from a backup, that may violate your integrity - I don't know a fully
> > safe solution
> Good point.
> > Also be aware that sometimes trigger do not fire.
> That would be worrying if it were random. Do you mean that they sometimes
> don't fire for no apparent reason?
> Charles
not random. Described here:
http://www.devx.com/dbzone/Article/31985|||On Jan 7, 12:57 pm, "Charles Law" <bl...@.nowhere.com> wrote:
> Hi John
> Any idea how performance compares between use of FK constraint (if it were
> available), trigger and function?
> Charles
> "John Bell" <jbellnewspo...@.hotmail.com> wrote in message
> news:7243FE54-4405-4EC3-80A6-F9ABFB98117E@.microsoft.com...
> > Hi
> > There is also the option of using a function in the constraint.
> > John
> > "Charles Law" wrote:
> >> Hi Anith
> >> Thanks for the quick reply. As I replied to Russell, with your and his
> >> vote,
> >> it looks like I will be looking at triggers.
> >> Cheers.
> >> Charles
> >> "Anith Sen" <an...@.bizdatasolutions.com> wrote in message
> >>news:uyA15%23UUIHA.5404@.TK2MSFTNGP03.phx.gbl...
> >> >> Is there any way round this, or am I trying to do something
> >> >> unreasonable? If it's not possible, what would others normally do in
> >> >> this situation?
> >> > You are not trying to do anything unreasonable. In fact, it is a very
> >> > common issue. Since DRI between databases are not supported, people
> >> > usually use triggers (a way of procedural referential integrity) to get
> >> > the job done.
> >> > --
> >> > Anith
I haven't repeated my benchmarks on 2005, but on 2000 FK is a clear
winner.|||I guess that's what one would expect, but good to have it confirmed (on
2000).
Charles
"Alex Kuznetsov" <alkuzo@.gmail.com> wrote in message
news:632fe8e1-a5ea-4d23-b90c-9e803f7f5a13@.p69g2000hsa.googlegroups.com...
> On Jan 7, 12:57 pm, "Charles Law" <bl...@.nowhere.com> wrote:
>> Hi John
>> Any idea how performance compares between use of FK constraint (if it
>> were
>> available), trigger and function?
>> Charles
>> "John Bell" <jbellnewspo...@.hotmail.com> wrote in message
>> news:7243FE54-4405-4EC3-80A6-F9ABFB98117E@.microsoft.com...
>> > Hi
>> > There is also the option of using a function in the constraint.
>> > John
>> > "Charles Law" wrote:
>> >> Hi Anith
>> >> Thanks for the quick reply. As I replied to Russell, with your and his
>> >> vote,
>> >> it looks like I will be looking at triggers.
>> >> Cheers.
>> >> Charles
>> >> "Anith Sen" <an...@.bizdatasolutions.com> wrote in message
>> >>news:uyA15%23UUIHA.5404@.TK2MSFTNGP03.phx.gbl...
>> >> >> Is there any way round this, or am I trying to do something
>> >> >> unreasonable? If it's not possible, what would others normally do
>> >> >> in
>> >> >> this situation?
>> >> > You are not trying to do anything unreasonable. In fact, it is a
>> >> > very
>> >> > common issue. Since DRI between databases are not supported, people
>> >> > usually use triggers (a way of procedural referential integrity) to
>> >> > get
>> >> > the job done.
>> >> > --
>> >> > Anith
> I haven't repeated my benchmarks on 2005, but on 2000 FK is a clear
> winner.|||Hi Charles
There is an example in the link Alex posted.
John
"Charles Law" wrote:
> Hi John
> Any idea how performance compares between use of FK constraint (if it were
> available), trigger and function?
> Charles
>
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:7243FE54-4405-4EC3-80A6-F9ABFB98117E@.microsoft.com...
> > Hi
> >
> > There is also the option of using a function in the constraint.
> >
> > John
> >
> > "Charles Law" wrote:
> >
> >> Hi Anith
> >>
> >> Thanks for the quick reply. As I replied to Russell, with your and his
> >> vote,
> >> it looks like I will be looking at triggers.
> >>
> >> Cheers.
> >>
> >> Charles
> >>
> >>
> >> "Anith Sen" <anith@.bizdatasolutions.com> wrote in message
> >> news:uyA15%23UUIHA.5404@.TK2MSFTNGP03.phx.gbl...
> >> >> Is there any way round this, or am I trying to do something
> >> >> unreasonable? If it's not possible, what would others normally do in
> >> >> this situation?
> >> >
> >> > You are not trying to do anything unreasonable. In fact, it is a very
> >> > common issue. Since DRI between databases are not supported, people
> >> > usually use triggers (a way of procedural referential integrity) to get
> >> > the job done.
> >> >
> >> > --
> >> > Anith
> >> >
> >>
> >>
> >>
>
>|||Thanks. It looks, though, like they do not fire if the settings are
incorrect, or if someone changes them. So long as the rules are followed
then there shouldn't be a problem?
Charles
"Alex Kuznetsov" <alkuzo@.gmail.com> wrote in message
news:53f039b7-b49f-4d75-86bc-5157ce745a97@.e23g2000prf.googlegroups.com...
> On Jan 7, 1:06 pm, "Charles Law" <bl...@.nowhere.com> wrote:
>> > I hope you realize that whatever solution you choose, it might not be
>> > fully watertight. If you ever need to restore one of your databases
>> > from a backup, that may violate your integrity - I don't know a fully
>> > safe solution
>> Good point.
>> > Also be aware that sometimes trigger do not fire.
>> That would be worrying if it were random. Do you mean that they sometimes
>> don't fire for no apparent reason?
>> Charles
> not random. Described here:
> http://www.devx.com/dbzone/Article/31985|||On Jan 8, 5:24 pm, "Charles Law" <bl...@.nowhere.com> wrote:
> Thanks. It looks, though, like they do not fire if the settings are
> incorrect, or if someone changes them. So long as the rules are followed
> then there shouldn't be a problem?
> Charles
> "Alex Kuznetsov" <alk...@.gmail.com> wrote in message
> news:53f039b7-b49f-4d75-86bc-5157ce745a97@.e23g2000prf.googlegroups.com...
> > On Jan 7, 1:06 pm, "Charles Law" <bl...@.nowhere.com> wrote:
> >> > I hope you realize that whatever solution you choose, it might not be
> >> > fully watertight. If you ever need to restore one of your databases
> >> > from a backup, that may violate your integrity - I don't know a fully
> >> > safe solution
> >> Good point.
> >> > Also be aware that sometimes trigger do not fire.
> >> That would be worrying if it were random. Do you mean that they sometimes
> >> don't fire for no apparent reason?
> >> Charles
> > not random. Described here:
> >http://www.devx.com/dbzone/Article/31985
Also use database permissions to make sure that your users cannot
truncate your parent table. Truncate also does not fire triggers. Bulk
insert also does not fire them either. Also dropping recreating a
parent table is a way around your triggers...|||> Also use database permissions to make sure that your users cannot
> truncate your parent table. Truncate also does not fire triggers. Bulk
> insert also does not fire them either. Also dropping recreating a
> parent table is a way around your triggers...
Ok. Point taken.
Cheers
Charles
"Alex Kuznetsov" <alkuzo@.gmail.com> wrote in message
news:35375a5f-32fd-4389-b3d9-b9160a923061@.i7g2000prf.googlegroups.com...
> On Jan 8, 5:24 pm, "Charles Law" <bl...@.nowhere.com> wrote:
>> Thanks. It looks, though, like they do not fire if the settings are
>> incorrect, or if someone changes them. So long as the rules are followed
>> then there shouldn't be a problem?
>> Charles
>> "Alex Kuznetsov" <alk...@.gmail.com> wrote in message
>> news:53f039b7-b49f-4d75-86bc-5157ce745a97@.e23g2000prf.googlegroups.com...
>> > On Jan 7, 1:06 pm, "Charles Law" <bl...@.nowhere.com> wrote:
>> >> > I hope you realize that whatever solution you choose, it might not
>> >> > be
>> >> > fully watertight. If you ever need to restore one of your databases
>> >> > from a backup, that may violate your integrity - I don't know a
>> >> > fully
>> >> > safe solution
>> >> Good point.
>> >> > Also be aware that sometimes trigger do not fire.
>> >> That would be worrying if it were random. Do you mean that they
>> >> sometimes
>> >> don't fire for no apparent reason?
>> >> Charles
>> > not random. Described here:
>> >http://www.devx.com/dbzone/Article/31985
> Also use database permissions to make sure that your users cannot
> truncate your parent table. Truncate also does not fire triggers. Bulk
> insert also does not fire them either. Also dropping recreating a
> parent table is a way around your triggers...