Opgelost Behouden van referentiële integriteit

[jbusser]

Wanneer ik mijn database gesplitst heb (Front- en back-end) is er dan een manier om referentiële integriteit af te dwingen in mijn Front-end, die dus koppelingen heeft naar de tabellen in de back-end waar de referentiële integriteit aan staat (trapsgewijs bijwerken).
Ik krijg nu steeds een sleutelconflict omdat er niet trapsgewijs wordt bijgewerkt (kan ik bij "relaties" ook niet aanzetten...

 

[OctaFish]

De relaties in een FE-BE constructie leg je in de backend, niet in de frontend. Zoals je gemerkt hebt, kán dat niet eens in de FE.

 

[xps351]

Het maakt niet uit of de database al dan niet gesplitst is. De relaties en hun eigenschappen definieer je daar waar de tabellen staan.
Geef eens wat meer details over de tabellen/relaties en het probleem. Uiteraard liefst met een voorbeeld bestand (de back-end).

 

[OctaFish]

Lijkt mij dat het antwoord al gegeven is? TS probeert de relaties in de FE te leggen, en dat kan niet. De FE, als laatste aanvulling, neemt de relaties over uit de BE. Ook in de queries etc. Kortom: in de praktijk merk je geen verschil tussen een gesplitste database met, of een niet-gesplitste. <Trapsgewijs bijwerken> heeft ook alleen zin bij eigen sleutelvelden; bij een sleutelveld op basis van een Autonummer is de optie nutteloos.

 

[NoellaG]

In de front-end kan je alleen relaties leggen/aanpassen in de queries. Daar kan je alleen spelen met de join types (inner of outer joins) en niet de restraints aanpassen (bv. referentiële integriteit, verplichte velden). Die zijn een eigenschap van de tabel.
Het is trouwens heel kort door de bocht om aan te nemen dat referentiële integriteit afdwingen een goede zaak is bij elke relatie. Dat moet je echt per situatie/relatie bekijken.

 

[OctaFish]

Het is trouwens heel kort door de bocht om aan te nemen dat referentiële integriteit afdwingen een goede zaak is bij elke relatie.

Ik heb alle berichten nog eens nagelezen, en zie nergens een bericht waarin iemand een korte bocht genomen heeft. Waarom haal je dát er nu weer bij? Voor de rest herhaal je alleen maar wat de anderen al gezegd hebben. Zullen we eerst eens afwachten wat TS te melden heeft?

 

[NoellaG]

Ik Waarom haal je dát er nu weer bij?

Omdat de gebruiker meldde dat hij een probleem had met de referentiële integriteit constraint. Miscchien is die helemaal niet nodig voor de gewraakte relatie en kan hij die er (in de BE) gewoon uithalen.

 

[OctaFish]

Zullen we eerst eens afwachten wat TS te melden heeft?

Waarom vooruitlopen op een situatie die je niet kent? Zo ken ik er nog wel een paar… Laat TS eerst wat meer vertellen voordat je wat in het rond gaat bazuinen. Op dit moment dus nutteloze en overbodige informatie. Sowieso is het zo dat een update met deze foutmelding in de BE ook niet zal werken, en dezelfde fout zal opleveren.

 

[NoellaG]

Sowieso is het zo dat een update met deze foutmelding in de BE ook niet zal werken, en dezelfde fout zal opleveren.

Niet als je eerst de constraint (ref int) disabled.

 

[OctaFish]

Hou eens op met onzinnige opmerkingen te poneren. Je vervuilt het topic en niemand zit hier op te wachten. Ga lekker een avondje naar de kroeg als je je verveelt.

 

[jbusser]

Weer een hoop losgemaakt vrees ik....
Ik heb een andere oplossing gevonden door het indexveld op duplicaten toestaan "ja" gezet maar nu voor het uitvoeren van een script een controle te doen of betreffende waarde al eens is ingevuld. In ieder geval bedankt!