Export og import av SQL scripts med lookup relasjoner

[HDSoftware]

Folkens, jeg har en database i MSSQL2005. Her har jeg relasjoner mellom tabeller definert med flagget "Enforce Foreign Key Constraints" satt til false. Dette fordi jeg har felter i tabeller som kan være NULL eller blank, men som skal søkes opp i andre tabeller hvis feltet har verdi. Dette fungerer helt topp.

 

Problem: Jeg lager et script av databasen i Enterprise Manager og ber om å få med alt mulig rart. Men når jeg kjører dette scriptet igjen så blir relasjonene satt med det nevnte flagget til TRUE uansett hva jeg forsøker. Har noen en løsning på dette? Er det en bugg?

 

Jeg ser det er forskjell på resultatet i SQL scriptet hvis jeg høyreklikke på selve tabellen og scripter den, enn når jeg høyreklikker på hele databasen for å scripte den. Forskjellen er at ved å høyreklikke på tabellen så produseres constraintene inne i tabell definisjonen, mens i alternativet for hele databasen, så kommer disse constraintene i bunnen av scriptet. Virker nesten som at disse ikke kjøres ordentlig.

 

 

Takker for alle bidrag

[HDSoftware]

Progresjon:

Jeg har nå kommet til at det er noe rart som skjer når jeg genererer scriptet i Enterprice manager. Det som skjer er at det genererte scriptet ikke produserer SQL statement for å sette det gitte flagget i det hele tatt. Eneste måten jeg klarer å få Enterprise Manager til å generere rett script er å scripte endringer. Da slenger den på følgende:

begin transaction
alter table dbo.MyTable
 NOCHECK CONSTRAINT FK_SomeRelatedTable
go
commit

Problemet er at dette scriptet aldri kommer med når jeg scripter hele databasen og det er jo helt håpløst. Betyr det at det er en bugg i enterprise manager eller er det en innstilling jeg ikke har satt?

[kaffenils]

Mulig det er en bug i SSMS.

 

Det jeg ikke skjønner er hvorfor du oppretter foreign keys som du deretter disabler. "Enforce Foreign Key Constraints", eller NOCHECK medfører jo at constrainten disables, og query optimizeren tar ikke hensyn til den.

Hvis du kjører med NOCHECK i produksjon så kunne du like gjerne latt være å opprette fremmednøkkelen i utgangspunktet.

[HDSoftware]

Mulig det er en bug i SSMS.

 

Det jeg ikke skjønner er hvorfor du oppretter foreign keys som du deretter disabler. "Enforce Foreign Key Constraints", eller NOCHECK medfører jo at constrainten disables, og query optimizeren tar ikke hensyn til den.

Hvis du kjører med NOCHECK i produksjon så kunne du like gjerne latt være å opprette fremmednøkkelen i utgangspunktet.

Joda, det er riktig, men når man lager et LINQ objekt mot en tabell så vil LINQ objektet ta med seg de "relaterte" postene automatisk for meg. Klart jeg veldig enkelt kan kode dette selv, men jo mere som overlates til SQL jo bedre etter min mening.

 

Men jeg er litt usikker på hva du mener med "Opprette for å slå av" Jeg gjør jo ingen ting annet en å lage en relasjon som sørger for at en multig parent er til stede. NoCheck saken gjør jo at jeg kan ha poster i CHILD der det ikke finnes en parent. Eller har jeg missforstått noe?

[kaffenils]

Joda, det er riktig, men når man lager et LINQ objekt mot en tabell så vil LINQ objektet ta med seg de "relaterte" postene automatisk for meg. Klart jeg veldig enkelt kan kode dette selv, men jo mere som overlates til SQL jo bedre etter min mening.

 

Men jeg er litt usikker på hva du mener med "Opprette for å slå av" Jeg gjør jo ingen ting annet en å lage en relasjon som sørger for at en multig parent er til stede. NoCheck saken gjør jo at jeg kan ha poster i CHILD der det ikke finnes en parent. Eller har jeg missforstått noe?

 

Jeg skrev nok litt rotete. Det NOCHECK gjør er å disable foreign key constrainten. Dette medfører også at query optimizeren ikke vil ta hensyn til den, og du kunne like gjerne ha slettet den.

Du sier at du ønsker å tillate NULL eller blank. MEd blank regner jeg med at du mener en tom streng? Hvorfor skulle du ha behov for en tom streng? Hvilken betydning har blank verdi vs NULL i systemet? Mulig du har en god grunn til å gjøre det slik, men for meg så lukter det foreløpig som en liten designfeil.

 

Jeg har ikke brukt LINQ og vet derfor ikke hvordan den bruker databasestrukturen for å lese data.

[HDSoftware]

Jeg lager et system tilsvarende Registry i programmet vårt. Der har jeg en tabell som er noe slik:

ROOT_TYPE LONG

KEY STRING

ValueName STRING

Value TEXT

UserID LONG

 

Så har jeg selvsagt en tabell med users. Hvis en post i Registry har RootType = REG_CURRENT_USER så vil feltet UserID ha en verdi. Når jeg lager et LINQ objekt mot disse to tabellene så vil VisualStudio sørge for at alle relaterte poster er tilstede når jeg spør etter en registry post. Noe slik:

MyDatabaseContext db = new MyDatabaseContext;
var reg = (from r in db.Registry
			 where r.Key == "Ett eller annet"
			 select r).single();

if(reg.Root_Type = REGTYP.CURRENT_USER)
 MessageBox.Show(reg.Users.Username);

Hvis jeg ikke har relasjonen på SQL serveren så må jeg i koden gjøre slik:

var reg = (from r in db.Registry
		   where r.Key == "Ett eller annet"
		   select r).Single();
if(reg.Root_Type = REGTYP.CURRENT_USER)
{
 var usr = (from u in db.Users
			 where u.UserID == reg.UserID
			 select u).single();
 MessageBox.Show(usr.Username);
}

 

Med andre ord to spørringer. Klart jeg kan lage LINQ requesten annerledes for å unngå dette, men noe av poenget med LINQ er jo at den forenkler kodingen drastisk ved å bruke databasen slik den er bygget opp.

Endret 24. september 2008 av HDSoftware

[kaffenils]

Nå er jeg sikkert helt dum, men jeg skjønner fortsatt ikke hvorfor du må disable fremmednøkkenel. Kan den ikke bare være aktiv da? For det er fremmednøkkelen mellom UserId-kolonnen og Users-tabellen vi snakker om.

Kan du ha verdier i UserId (med unntak av NULL) som ikke har en referanse i Users-tabellen?

Endret 24. september 2008 av kaffenils

[HDSoftware]

Kan du ha verdier i UserId (med unntak av NULL) som ikke har en referanse i Users-tabellen?

Nå nærmer vi oss noe her ;-)

Det er slik at det kan lages poster som ikke har en UserGUID. Problemet er at noen av våre programmer ikke er skrevet i C#, men i Clarion og Clarion har ikke begrepet NULL på slikt. Det vil si at Clarion programmene kan finne på å lagre en tom streng. SQL serveren skjønner ikke at en tom streng ikke er en verdi og prøver å slå opp i Users tabellen, finner ingen users med ID = "" og kaster en feil. Når du sier "Slå av constraint" så skjønner jeg ikke hva du mener. Betyr den avkryssingen at jeg definerer en relasjon og så tar den vekk igjen? Jeg tror nemlig ikke det, for da ville ikke Visual Studio ha presentert meg USERS i LINQ

[kaffenils]

Det er slik at det kan lages poster som ikke har en UserGUID. Problemet er at noen av våre programmer ikke er skrevet i C#, men i Clarion og Clarion har ikke begrepet NULL på slikt. Det vil si at Clarion programmene kan finne på å lagre en tom streng. SQL serveren skjønner ikke at en tom streng ikke er en verdi og prøver å slå opp i Users tabellen, finner ingen users med ID = "" og kaster en feil.

 

Nå går jeg ut fra at UserGUID er av type varchar, og ikke INT slik beskrevet i eksempelet ditt.

Hvis problemet ligger i Clarion så kan du jo løse det ved å bruke stored procedures. Da kan prosedyren gjøre om '' til NULL, og ved lesing kan du heller gjøre om NULL til '' hvis du må. Kanskje ikke verdens beste løsning, men kanskje allikvel bedre en å disable foreign key constraints.

 

Når du sier "Slå av constraint" så skjønner jeg ikke hva du mener. Betyr den avkryssingen at jeg definerer en relasjon og så tar den vekk igjen? Jeg tror nemlig ikke det, for da ville ikke Visual Studio ha presentert meg USERS i LINQ

Hehe. Godt jeg ikke utdannet meg til lærer hvis jeg er så dårlig til å forklare.

Det jeg prøver å si er at krysset (som er ekvivalent med en NOCHECK constraint) gjør at constrainten blir disablet. Mao. så vil du kunne få inkonsistente data. Som jeg har skrevet lenger oppe i posten så vill jeg heller prøvd å løse det ved bruke av stored procedures, enn ved å disable constrainten.