[Access/SQL] problemen met referentiele integriteit

[Verwijderd]

Ik heb de database van een oud boekhoudprogramma waarvan ik de gegevens uit een bepaald jaar moet hebben. Ik ben hiervoor een programma aan het schrijven in C#, nu heb ik het programma goed als klaar, maar nu kom ik er achter dat er bij de select query die ik ingegeven heb, meerdere factuurnummers weergegeven worden.

De database is gemaakt voor SQL server. Elke tabel heeft een primaire sleutel en linkt mooi naar de andere tabel. Maar het probleem is dat bij de tabel verkoopfactuur en verkoopfactuurregel geen referentiele integriteit kan afgedwongen worden. Je mag toch aannemen dat het zo is dat 1 factuur meerdere regels heeft.

Ik heb hiervoor de tabel in MS Access 2003 gekoppeld of geimporteerd en op basis van die tabellen de relaties gemaakt. Access is dus degene die begint te zeiken over die integriteit. Bij tabellen als de Relatie met Adres (1 contactpersoon cq debiteur cq crediteur kan immers meerdere adressen hebben) kan die wel referentiele integriteit afdwingen. Wat kan nu het probleem zijn?

Alle primaire sleutels zijn autogenummerd.

De query:

SQL:

SELECT Relatie.BedrijfsNaam, Adres.Adres, VerkoopFactuur.VerkoopFactuurDatum, VerkoopFactuurRegel.BedragExcl, VerkoopFactuur.VerkoopFactuurID, VerkoopFactuurRegel.VerkoopFactuurID, VerkoopFactuurRegel.VerkoopFactuurRegelID
FROM Artikel, ((Relatie INNER JOIN Adres ON Relatie.RelatieID = Adres.RelatieID) INNER JOIN VerkoopFactuur ON Relatie.RelatieID = VerkoopFactuur.RelatieID) INNER JOIN VerkoopFactuurRegel ON VerkoopFactuur.VerkoopFactuurID = VerkoopFactuurRegel.VerkoopFactuurID;

[whoami]

Dit heeft niets met software engineering of architectuur te maken, aangezien de structuur / architectuur van de applicatie hier niet ter discussie staat

-> PRG

Heb je die ref. integriteit wel in Sql Server ? Normaal gezien wel; en 'hoe' klaagt Access hierover ? Welke melding geeft Access ?
_{de laatste glazen bol heeft gorgi_19 laten vallen.}

edit:
en NMe is traag.

[ Voor 43% gewijzigd door whoami op 23-05-2006 22:35 ]

[NMe]

Waar hoort mijn topic?
Implementatieproblemen horen in Programming.

SEA>>PRG

edit:
whoami, jij voorkruiper.

[ Voor 15% gewijzigd door NMe op 23-05-2006 22:34 ]

[The Eagle]

Ik kan me sterk vergissen, maar als ik het zo zie kan acces niet echt met gecombinerde primary keys omgaan. Wat een factuurregel namelijk uniek maak, is de combinatie van factuur en factuurregel. Probeer het verkoopfactuurregelID ook eens te koppelen in access als datkan, ik denk dat je dan verder komt
Overigens is dit precies de reden waarom ik Access niet als een database zie. MS zou graag zien dat ik dat wel deed, maar als het niet eens echte SQL snapt en dit soort fratsen nodig zijn, dan mag je jezelf in mijn optiek alleen een slcht excuus voor een DBMS noemen

Maar ff iets anders: waarom maak je niet gewoon een stuk echte SQL Da's dan toch veel makkelijker? D'r zal toch wel ergens een ODBC koppeling zijn die je kunt gebruiken behalve die van access? Desnoods lees je het middels een spool-commando in in een textfile en lees je die uit in je C-programma, lijkt me als je C-programmeur bent toch net iets handiger als dit access-geklooi

[Verwijderd]

Bla Het is geen C programma (ben echt geen programmeur) maar een C# die ik aan het schrijven ben, athans dat ben ik aan het proberen. Nogmaals zal ik de stappen die ik verricht heb beschrijven:

- ik heb een MS SQL Server geinstalleerd
- ik heb oude database (de mdf en de ldf bestanden) attached aan de SQL Server
- het programma wat ik geschreven heb maakt gebruik van ODBC koppelingen
- de MS SQL Koppelingen gaf constant verkeerde meldingen (de connectie ging goed maar de query gaf constant errors)
- ik heb besloten de database naar MS Access te exporteren
- daarna heb ik het geexporteerd naar MySQL (dit omdat ik een linux server heb en omdat ik de client een PII niet wil belasten met een k*t pakket als de MSSQL Server)
- de primaire sleutels in de MSSQL Server heb ik bekeken en alleen de ID van gelijknamige tabel is primaire sleutel (dus VerkoopFactuurRegelID is primaire sleutel in VerkoopFactuurRegel)
- dit heb ik in MS Access ook zo gedaan
- de resultaten zijn dat de query die ik in MySQL doe met de geexporteerde waarden overeen komen met de resultaten van de query in Access (of dit overeen komt met de waarden uit de MSSQL server moet ik nog even testen)
- het resultaat is dus dat ik 1 factuurregel heb die meerdere keren voorkomt, terwijl deze in de dbase maar 1 keer voorkomt. 1 regel heeft ook maar 1 factuurnummer en dus maar 1 relatienummer.

Ik snap er weinig meer van moet ik zeggen....

Voor de duidelijkheid die oude MSSQL Database heb ik niet gemaakt.
Wat betreft de meldingen die Access geeft zijn zodra ik een inner join wil leggen waarbij referentiele integriteit afgedwongen wordt, hij zegt dat dit niet mogelijk is omdat de waarden of zo niet overeen komen. Het was iig een hele grote melding.

Btw (by the way) ik heb bij de query wel een extra WHERE statement toegevoegd aan de bovenstaande query (ik moet namelijk wel een bepaalde klant waar wij iets aan verkocht hebben terugkrijgen) namelijk

SQL:

 Relatie.BedrijfsNaam LIKE '%{0}%'

De {0} linkt in C# naar het opgegeven textveld wat gebruikt wordt.

code:

string commandstring = string.format("Select statement WHERE Relatie.Bedrijfsnaam LIKE '%{0}%'", textboxklNaam);

Kan er iets met die LIKE gebeuren dan wat niet goed gaat? Ik kan in dit geval natuurlijk ook geen = gebruiken want dan moet je precies de naam intypen anders geef die geen resultaat terug en dat is natuurlijk onzin.

[ Voor 19% gewijzigd door Verwijderd op 24-05-2006 11:47 ]

[sig69]

Verwijderd schreef op woensdag 24 mei 2006 @ 11:41:
Bla Het is geen C programma (ben echt geen programmeur) maar een C# die ik aan het schrijven ben, athans dat ben ik aan het proberen. Nogmaals zal ik de stappen die ik verricht heb beschrijven:

- ik heb een MS SQL Server geinstalleerd
- ik heb oude database (de mdf en de ldf bestanden) attached aan de SQL Server
- het programma wat ik geschreven heb maakt gebruik van ODBC koppelingen
- de MS SQL Koppelingen gaf constant verkeerde meldingen (de connectie ging goed maar de query gaf constant errors)
- ik heb besloten de database naar MS Access te exporteren

De query geeft errors dus exporteren we het maar naar Acces?

- daarna heb ik het geexporteerd naar MySQL (dit omdat ik een linux server heb en omdat ik de client een PII niet wil belasten met een k*t pakket als de MSSQL Server)

K*tpakket? Niet om terug te flamen maar in mijn ogen is MSSQL meer DBMS dan MySQL

- de primaire sleutels in de MSSQL Server heb ik bekeken en alleen de ID van gelijknamige tabel is primaire sleutel (dus VerkoopFactuurRegelID is primaire sleutel in VerkoopFactuurRegel)
- dit heb ik in MS Access ook zo gedaan
- de resultaten zijn dat de query die ik in MySQL doe met de geexporteerde waarden overeen komen met de resultaten van de query in Access (of dit overeen komt met de waarden uit de MSSQL server moet ik nog even testen)
- het resultaat is dus dat ik 1 factuurregel heb die meerdere keren voorkomt, terwijl deze in de dbase maar 1 keer voorkomt. 1 regel heeft ook maar 1 factuurnummer en dus maar 1 relatienummer.

Ik snap er weinig meer van moet ik zeggen....

Voor de duidelijkheid die oude MSSQL Database heb ik niet gemaakt.
Wat betreft de meldingen die Access geeft zijn zodra ik een inner join wil leggen waarbij referentiele integriteit afgedwongen wordt, hij zegt dat dit niet mogelijk is omdat de waarden of zo niet overeen komen. Het was iig een hele grote melding.

Juist deze melding is waarin we geinteresseerd zijn, met "een hele grote melding" kunnen we niet zoveel.

Btw (by the way) ik heb bij de query wel een extra WHERE statement toegevoegd aan de bovenstaande query (ik moet namelijk wel een bepaalde klant waar wij iets aan verkocht hebben terugkrijgen) namelijk

SQL:

 Relatie.BedrijfsNaam LIKE '%{0}%'

De {0} linkt in C# naar het opgegeven textveld wat gebruikt wordt.

code:

string commandstring = string.format("Select statement WHERE Relatie.Bedrijfsnaam LIKE '%{0}%'", textboxklNaam);

Waarom gebruik je geen parametrized queries? Google eens op "Sql injection"..

Kan er iets met die LIKE gebeuren dan wat niet goed gaat? Ik kan in dit geval natuurlijk ook geen = gebruiken want dan moet je precies de naam intypen anders geef die geen resultaat terug en dat is natuurlijk onzin.

Ik heb het gevoel dat er gewoon een fout in je query zit. Post je query (edit: query staat al inde TS) eens, je tabellen en de foutmelding die je kreeg.

[Verwijderd]

sig69 schreef op woensdag 24 mei 2006 @ 12:11:
[...]

De query geeft errors dus exporteren we het maar naar Acces?

[...]

K*tpakket? Niet om terug te flamen maar in mijn ogen is MSSQL meer DBMS dan MySQL

[...]

Juist deze melding is waarin we geinteresseerd zijn, met "een hele grote melding" kunnen we niet zoveel.

[...]

Waarom gebruik je geen parametrized queries? Google eens op "Sql injection"..

[...]

Ik heb het gevoel dat er gewoon een fout in je query zit. Post je query (edit: query staat al inde TS) eens, je tabellen en de foutmelding die je kreeg.

Ten eerste ik heb niet besloten om naar Access te exporteren, ik heb besloten om via Access naar MySQL te exporteren. Omdat er geen makkelijke weg is om van MSSQL naar Mysql te komen heb ik het zo gedaan. 0 errors en de dbase is hetgeen wat ik nodig heb. Verder is het mijn keuze geweest om van MSSQL niet gebruik te maken. Ik vind het een k*t pakket en daarmee is het klaar. Het is mijn mening en daar zul je het mee moeten doen.

Maar goed nu even ontopic. Ik zal van een paar tabellen de structuur even posten en de daarbij gebruikte query. Voor de duidelijkheid er zit geen fout in mijn query voor zover ik weet, want immers ik krijg geen foutmelding op mijn query ik krijg alleen redundantie (3 dezelfde factuurregels die precies hetzelfde zijn).

De foutmelding zit toevallig in Access omdat ik wilde weten waarom ik 3 dezelfde gegevens kreeg. Ik deed even wat pielen met de relaties en zag gewoon dat die geen referentiele integriteit kregen. Ik kan de foutmelding even niet terug krijgen maar het is een melding dat die dat gewoon niet af kan dwingen. Volgens mij is het zo'n standaard Access foutmelding die je bij elke database krijgt ongeacht de structuur.

tabel adres:

Adres
Veld Type Null Standaardwaarde
AdresID int(10) Nee
RelatieID int(10) Ja NULL
AdresTypeID int(10) Ja NULL
Naam varchar(50) Ja NULL
Adres varchar(50) Ja NULL
Postcode varchar(7) Ja NULL
Plaats varchar(50) Ja NULL
Land varchar(50) Ja NULL
Telefoon1 varchar(20) Ja NULL
Telefoon2 varchar(20) Ja NULL
Mobiel varchar(20) Ja NULL
Fax varchar(20) Ja NULL
Email varchar(50) Ja NULL
WWW varchar(255) Ja NULL
HoofdAdres bit(1) Nee
LaatsteWijziging var( Ja NULL
LaatsteWijzigingWerknemerID int(10) Ja NULL
LaatsteWijzigingDatumTijd datetime Ja NULL

tabel relatie

RelatieID int(10) Nee
RelatieType int(10) Ja NULL
RelatieNummer int(10) Ja NULL
SelectieCode varchar(18) Ja NULL
BedrijfsNaam varchar(50) Ja NULL
BedrijfsToevoeging varchar(50) Ja NULL
ValutaID int(10) Ja NULL
RelatieSinds datetime Ja NULL
BTWBerekenen bit(1) Nee
BTWNummer varchar(20) Ja NULL
BankGiroRekeningNummer varchar(25) Ja NULL
KredietLimiet decimal(19,4) Ja NULL
AanmanenDagen int(10) Ja NULL
Faktoring int(10) Ja NULL
Incasso bit(1) Nee
IncassoTermijn int(10) Ja NULL
BetalingsTermijn int(10) Ja NULL
PrijslijstID int(10) Ja NULL
ZoekCode varchar(10) Ja NULL
TaalID int(10) Ja NULL
Toeleverancier bit(1) Nee
Betalingsconditie longtext Ja NULL
Betalingsconditie2 longtext Ja NULL
Betalingsconditie3 longtext Ja NULL
OmzetRekening int(10) Ja NULL
RapportLayoutGroepID int(10) Ja NULL
Expediteur bit(1) Nee
FactuurToeslag decimal(19,4) Ja NULL
FactuurKorting decimal(19,4) Ja NULL
WaardePuntenSaldo int(10) Ja NULL
RitCode varchar(10) Ja NULL
BrandstofVergoeding bit(1) Nee
DistributieVergoeding bit(1) Nee
SorteerVergoeding bit(1) Nee
EmballageVergoedng bit(1) Nee
ExtraVeld1 varchar(255) Ja NULL
ExtraVeld2 varchar(255) Ja NULL
ExtraVeld3 varchar(255) Ja NULL
ExtraVeld4 bit(1) Nee
Opmerkingen longtext Ja NULL
GrootboekNummer int(10) Ja NULL
UwRelatieNummerBijRelatie int(10) Ja NULL
ParentRelatieID int(10) Ja NULL
LaatsteWijziging var( Ja NULL
LaatsteWijzigingWerknemerID int(10) Ja NULL
LaatsteWijzigingDatumTijd datetime Ja NULL
RelatieGroepID int(10) Ja NULL

Tabel Artikel

ArtikelID int(10) Nee
ArtikelGroepID int(10) Ja NULL
BTWCodeID int(10) Ja NULL
RelatieID int(10) Ja NULL
ArtikelCode varchar(18) Ja NULL
OmschrijvingDuits varchar(50) Ja NULL
OmschrijvingFrans varchar(50) Ja NULL
OmschrijvingEngels varchar(50) Ja NULL
ArtikelCodeLeverancier varchar(18) Ja NULL
ArtikelOmschrijvingLeverancier varchar(100) Ja NULL
ArtikelBarcode varchar(15) Ja NULL
MagazijnLokatie varchar(18) Ja NULL
Omschrijving varchar(100) Ja NULL
VerpakkingsEenheid varchar(10) Ja NULL
VerpakkingsAantal decimal(10,2) Ja NULL
VoorraadBegin int(10) Ja NULL
VoorraadMinimum int(10) Ja NULL
VoorraadMaximum int(10) Ja NULL
BestelMinimum int(10) Ja NULL
Levertijd int(10) Ja NULL
InkoopPrijs decimal(19,4) Ja NULL
VerkoopPrijs decimal(19,4) Ja NULL
EmballageBedrag decimal(19,4) Ja NULL
VoorraadArtikel bit(1) Nee
Gewicht decimal(18,0) Ja NULL
Lengte decimal(18,0) Ja NULL
Breedte decimal(18,0) Ja NULL
Hoogte decimal(18,0) Ja NULL
OmschrijvingLangNL varchar(255) Ja NULL
OmschrijvingLangD varchar(255) Ja NULL
OmschrijvingLangF varchar(255) Ja NULL
OmschrijvingLangE varchar(255) Ja NULL
ArtikelNummerOud varchar(20) Ja NULL
Afmeting varchar(50) Ja NULL
GemiddeldeInkoopPrijs decimal(19,4) Ja NULL
NettoInkoopPrijs decimal(19,4) Ja NULL
SorteerVergoeding decimal(19,4) Ja NULL
DistributieVergoeding decimal(19,4) Ja NULL
WaardePunten decimal(18,0) Ja NULL
WaardePuntenVanToepassing bit(1) Nee
AlcoholPercentage decimal(18,0) Ja NULL
StatistiekNummer varchar(20) Ja NULL
Kleur varchar(100) Ja NULL
FrameHoogte varchar(50) Ja NULL
FrameNummer varchar(50) Ja NULL
SlotNummer varchar(50) Ja NULL
SleutelNummer varchar(50) Ja NULL
Sexe varchar(2) Ja NULL
RemUitvoering varchar(20) Ja NULL
VolgNummer int(10) Ja NULL
Actief bit(1) Nee
LaatsteWijziging var( Ja NULL
LaatsteWijzigingWerknemerID int(10) Ja NULL
LaatsteWijzigingDatumTijd datetime Ja NULL
Leverancier1ID int(10) Ja NULL
Leverancier2ID int(10) Ja NULL
Leverancier3ID int(10) Ja NULL
GemInkoopprijs decimal(19,4) Ja NULL
ExtraOpmerking longtext Ja NULL
ArtHoofdGroep int(10) Ja NULL
ArtProductGroep int(10) Ja NULL
ArtSubGroep int(10) Ja NULL
ArtSubSubGroep int(10) Ja NULL
Montagevoorschrift int(10) Ja NULL
BevestigingsSysteem int(10) Ja NULL
ArtikelAfbeeldingKlein varchar(11) Ja NULL
ArtikelAfbeeldingGroot varchar(11) Ja NULL
ArtikelTag varchar(11) Ja NULL
PositieTekening varchar(11) Ja NULL
OmdoosAfmeting varchar(15) Ja NULL
PalletAantal int(10) Ja NULL
TuV bit(1) Nee
Internet bit(1) Nee
Afneembaar bit(1) Nee
Octrooi bit(1) Nee
NieuwArtikel bit(1) Nee
OpOfferte bit(1) Nee
Uitlopend bit(1) Nee
FamilieNaam varchar(25) Ja NULL
TagNL1 varchar(100) Ja NULL
TagNL2 varchar(100) Ja NULL
TagNL3 varchar(100) Ja NULL
TagNL4 varchar(100) Ja NULL
TagNL5 varchar(100) Ja NULL
TagD1 varchar(100) Ja NULL
TagD2 varchar(100) Ja NULL
TagD3 varchar(100) Ja NULL
TagD4 varchar(100) Ja NULL
TagD5 varchar(100) Ja NULL
TagE1 varchar(100) Ja NULL
TagE2 varchar(100) Ja NULL
TagE3 varchar(100) Ja NULL
TagE4 varchar(100) Ja NULL
TagE5 varchar(100) Ja NULL
TagF1 varchar(100) Ja NULL
TagF2 varchar(100) Ja NULL
TagF3 varchar(100) Ja NULL
TagF4 varchar(100) Ja NULL
TagF5 varchar(100) Ja NULL

tabel verkoopfactuur

VerkoopFactuurID int(10) Nee
VerkoopOrderID int(10) Ja NULL
RelatieID int(10) Ja NULL
WerknemerID int(10) Ja NULL
VerkoopFactuurNummer int(10) Ja NULL
VerkoopFactuurDatum datetime Ja NULL
Periode int(10) Ja NULL
VerkoopNota bit(1) Nee
BedragBruto decimal(19,4) Ja NULL
BedragNetto decimal(19,4) Ja NULL
BedragBTWHoog decimal(19,4) Ja NULL
BedragBTWLaag decimal(19,4) Ja NULL
BedragBetaald decimal(19,4) Ja NULL
BedragTerIncasso decimal(19,4) Ja NULL
BetaalDatum datetime Ja NULL
ValutaID int(10) Ja NULL
Koers decimal(19,4) Ja NULL
BetalingsTermijn int(10) Ja NULL
ExtraTekstBoven longtext Ja NULL
ExtraTekstOnder longtext Ja NULL
Afgeboekt bit(1) Nee
Verwerkt bit(1) Nee
FactuurToeslag decimal(18,0) Ja NULL
FactuurKorting decimal(18,0) Ja NULL
FactuurToeslagBedrag decimal(19,4) Ja NULL
FactuurKortingBedrag decimal(19,4) Ja NULL
LaatsteWijziging var( Ja NULL
LaatsteWijzigingWerknemerID int(10) Ja NULL
LaatsteWijzigingDatumTijd datetime Ja NULL
DistributieVergoeding decimal(19,4) Ja NULL
BrandstofVergoeding decimal(19,4) Ja NULL
SorteerVergoeding decimal(19,4) Ja NULL
Emballage decimal(19,4) Ja NULL
WaardePunten decimal(18,0) Ja NULL
Vrachtkosten decimal(19,4) Ja NULL
Administratiekosten decimal(19,4) Ja NULL
OrigineelID int(10) Ja NULL
Referentie varchar(100) Ja NULL
AdresID int(10) Ja NULL
IRIS bit(1) Nee

tabel verkoopfactuurregel

VerkoopFactuurRegelID int(10) Nee
VerkoopFactuurID int(10) Ja NULL
VerkoopOrderRegelID int(10) Ja NULL
PakbonRegelID int(10) Ja NULL
ArtikelID int(10) Ja NULL
ArtikelOmschrijving varchar(100) Ja NULL
BTWCodeID int(10) Ja NULL
BTWPercentage decimal(18,0) Ja NULL
Omschrijving longtext Ja NULL
Aantal decimal(10,2) Ja NULL
ExtraKortingBedrag decimal(19,4) Ja NULL
ExtraKortingPercentage decimal(18,0) Ja NULL
EmballageBedrag decimal(19,4) Ja NULL
BedragExcl decimal(19,4) Ja NULL
BedragBTW decimal(19,4) Ja NULL
BedragValutaExcl decimal(19,4) Ja NULL
BedragRegel decimal(19,4) Ja NULL
GrootboekNummer int(10) Ja NULL
GrootboekNummerOmschrijving varchar(50) Ja NULL
ValutaID int(10) Ja NULL
Koers double(53,0) Ja NULL
RegelNummer int(10) Ja NULL
LaatsteWijziging var( Ja NULL
LaatsteWijzigingWerknemerID int(10) Ja NULL
LaatsteWijzigingDatumTijd datetime Ja NULL
Inkoopprijs decimal(10,2) Ja NULL


Nogmaals het is niet mijn ontwerp en er zit een heel jaar aan gegevens in dus ik ga het ook niet gebruiken of aanpassen. Tevens ga ik ook geen data tonen omdat het bedrijfsinformatie is. ik hoop dat jullie er wat mee kunnen.

[SPee]

[code=sql]
SELECT Relatie.BedrijfsNaam, Adres.Adres, VerkoopFactuur.VerkoopFactuurDatum, VerkoopFactuurRegel.BedragExcl, VerkoopFactuur.VerkoopFactuurID, VerkoopFactuurRegel.VerkoopFactuurID, VerkoopFactuurRegel.VerkoopFactuurRegelID
FROM Artikel, ((Relatie INNER JOIN Adres ON Relatie.RelatieID = Adres.RelatieID) INNER JOIN VerkoopFactuur ON Relatie.RelatieID = VerkoopFactuur.RelatieID) INNER JOIN VerkoopFactuurRegel ON VerkoopFactuur.VerkoopFactuurID = VerkoopFactuurRegel.VerkoopFactuurID;
[/sql]

maak er

SQL:

SELECT Relatie.BedrijfsNaam, Adres.Adres, VerkoopFactuur.VerkoopFactuurDatum, VerkoopFactuurRegel.BedragExcl, VerkoopFactuur.VerkoopFactuurID, VerkoopFactuurRegel.VerkoopFactuurID, VerkoopFactuurRegel.VerkoopFactuurRegelID 
FROM Relatie, Adres, VerkoopFactuur, VerkoopFactuurRegel
WHERE relatie.relatieid = adres.relatieid and relatie.relatieid = verkoopfactuur.relatieid and verkoopfactuur.verkoopfactuurid = verkoopfactuurregel.verkoopfactuurid and relatie.bedrijfsnaam like '%naam'

Wat doet die Artikel tabel er eigenlijk als je er niets mee doet?
Volgens mij gaat het ergens fout op je inner join queries. Probeer ook de query analyzer van MS eens uit.

[sig69]

Wat me opvalt, is dat de tabel Artikel niet gebruikt wordt in je query of joins. Misschien dat het hier iets mee te maken heeft?

Hmm, spuit 11.
Maar het kan in ieder geval best zijn dat dit een beetje vreemde resultaten geeft.

[ Voor 30% gewijzigd door sig69 op 24-05-2006 12:53 ]

[Verwijderd]

SPee schreef op woensdag 24 mei 2006 @ 12:50:
[code=sql]
SELECT Relatie.BedrijfsNaam, Adres.Adres, VerkoopFactuur.VerkoopFactuurDatum, VerkoopFactuurRegel.BedragExcl, VerkoopFactuur.VerkoopFactuurID, VerkoopFactuurRegel.VerkoopFactuurID, VerkoopFactuurRegel.VerkoopFactuurRegelID
FROM Artikel, ((Relatie INNER JOIN Adres ON Relatie.RelatieID = Adres.RelatieID) INNER JOIN VerkoopFactuur ON Relatie.RelatieID = VerkoopFactuur.RelatieID) INNER JOIN VerkoopFactuurRegel ON VerkoopFactuur.VerkoopFactuurID = VerkoopFactuurRegel.VerkoopFactuurID;
[/sql]

maak er

SQL:

SELECT Relatie.BedrijfsNaam, Adres.Adres, VerkoopFactuur.VerkoopFactuurDatum, VerkoopFactuurRegel.BedragExcl, VerkoopFactuur.VerkoopFactuurID, VerkoopFactuurRegel.VerkoopFactuurID, VerkoopFactuurRegel.VerkoopFactuurRegelID 
FROM Relatie, Adres, VerkoopFactuur, VerkoopFactuurRegel
WHERE relatie.relatieid = adres.relatieid and relatie.relatieid = verkoopfactuur.relatieid and verkoopfactuur.verkoopfactuurid = verkoopfactuurregel.verkoopfactuurid and relatie.bedrijfsnaam like '%naam'

Wat doet die Artikel tabel er eigenlijk als je er niets mee doet?
Volgens mij gaat het ergens fout op je inner join queries. Probeer ook de query analyzer van MS eens uit.

Klopt wat je zegt, uiteindelijk moet die artikel tabel ook wel gebruikt worden, want er staan namelijk velden in die ik uiteindelijk wel wil laten zien

ik pas de query even aan:

SQL:

SELECT Artikel.Kleur, Relatie.BedrijfsNaam, Adres.Adres, VerkoopFactuur.VerkoopFactuurDatum, VerkoopFactuurRegel.BedragExcl, VerkoopFactuur.VerkoopFactuurID, VerkoopFactuurRegel.VerkoopFactuurID, VerkoopFactuurRegel.VerkoopFactuurRegelID 
FROM Artikel, ((Relatie INNER JOIN Adres ON Relatie.RelatieID = Adres.RelatieID) INNER JOIN VerkoopFactuur ON Relatie.RelatieID = VerkoopFactuur.RelatieID) INNER JOIN VerkoopFactuurRegel ON VerkoopFactuur.VerkoopFactuurID = VerkoopFactuurRegel.VerkoopFactuurID
WHERE Relatie.BedrijfsNaam LIKE '%naam%';

Ik vind het maar een vaag boeltje die opgezette database, ik kan er geen touw aan vastknopen.

[sig69]

Nu is Artikel.kleur nog niet in de join opgenomen. Als ik een gok mag doen: er staan 3 kleuren in de database of dit is nog niet de volledige query? Er is nu namelijk nog geen enkele manier waarop ik zie wat Artikel in de query zou doen.
Een koppeling tussen Verkoopregel.ArtikelID en Artikel.ID zou ik me wel in kunnen denken.

[ Voor 53% gewijzigd door sig69 op 24-05-2006 13:18 ]

[Verwijderd]

sig69 schreef op woensdag 24 mei 2006 @ 13:16:
Nu is Artikel.kleur nog niet in de join opgenomen. Als ik een gok mag doen: er staan 3 kleuren in de database of dit is nog niet de volledige query? Er is nu namelijk nog geen enkele manier waarop ik zie wat Artikel in de query zou doen.
Een koppeling tussen Verkoopregel.ArtikelID en Artikel.ID zou ik me wel in kunnen denken.

Nou niet helemaal, het artikel is niet het enige probleem, het zijn de relaties adressen die ook vaker voorkomen. Maar of ik het nu doe zonder of met artikel is niet zo interessant. Er komt toch hetzelfde uit.

Artikel hoeft ook verder weinig te doen..

Er komt een vraag bij mij ik heb in 2000 een artikel bij jullie gekocht die ik nu wil inruilen. Nou mooi zeg ik, ik vragen wie hij of zei is, de klant geeft me zijn gegevens (of te wel de naam).

Wat ik dan wil weten is, heeft hij of zei dat artikel daadwerkelijk gekocht, wanneer en tegen welke prijs. De kleur, hoogte en maten zijn dan gewoon eigenschappen van het verkochte artikel. Het gaat bij mij dus het meest om de factuurregel, de factuur, de relatie en het adres van deze relatie. Het artikel zou in dit geval gewoon moeten blijken uit de factuurregel.

Ben ik nu gek of is deze gedachte nu helemaal verkeerd?

[ Voor 35% gewijzigd door Verwijderd op 24-05-2006 13:32 ]

[sig69]

Nee.

Wat ik in zo'n geval vaak doe is gewoon simpel beginnen:
-Maak een query die de juiste relatie uit de database haalt
Als dat goed gaat:
-Breid de query uit met een join op Adres
Als dat goed gaat... etc.

Wat ik me nu overigens bedenk, gaat het niet fout op de join met relatie en adres? (Zoals je zei, meerdere adressen). Als je de naam van je relatie hebt, en je zoekt een verkoopregel, dan maakt het adres toch niet uit?

Tenzij je op zoek ben naar een afleveradres ofzo, dan zou je nog iets met Adres.AdresTypeID moeten doen

[ Voor 14% gewijzigd door sig69 op 24-05-2006 14:08 ]

[Verwijderd]

sig69 schreef op woensdag 24 mei 2006 @ 14:04:
Nee.

Wat ik in zo'n geval vaak doe is gewoon simpel beginnen:
-Maak een query die de juiste relatie uit de database haalt
Als dat goed gaat:
-Breid de query uit met een join op Adres
Als dat goed gaat... etc.

Wat ik me nu overigens bedenk, gaat het niet fout op de join met relatie en adres? (Zoals je zei, meerdere adressen). Als je de naam van je relatie hebt, en je zoekt een verkoopregel, dan maakt het adres toch niet uit?

Tenzij je op zoek ben naar een afleveradres ofzo, dan zou je nog iets met Adres.AdresTypeID moeten doen

Nou ja was dat maar zo makkelijk, maar de relaties zijn in veel geval particulieren en maar een paar crediteuren. Dat krijg je met zo'n klein zaakje. Dat heeft de maker gewoon bij elkaar gezet in het ontwerp. Het probleem is als ik mevrouw jansen krijg dan kan ik er op rekenen dat er 100 jansens zijn die allemaal een keer wat hebben aangeschaft. Dan heb ik het adres nodig of postcode of plaats of wat dan ook. Maar iig wel meer gegevens dan alleen de naam. Daarom heb ik adres nodig.

Wat betreft de query ik zal jou raad is opvolgen en later deze dag de query beginnen met iets simpels en dan langzaam uitbreiden.

Ik heb even jou bericht nog een keer gelezen, volgens mij heb ik het niet duidelijk verteld.
Ik krijg niet meer adressen onder 1 relatie.

Het probleem is simpel gezegd ik krijg meerdere dezelfde records uit de query. Dat is het stomme ervan.

[ Voor 10% gewijzigd door Verwijderd op 24-05-2006 14:19 ]

[TheRookie]

't is een heel voor-de-hand-liggende vraag; maar dat oude boekhoudpakket gebruiken is geen optie ?
Al is het tijdelijk, dan kan je nog steeds met de profiler de door het pakket gegenereerde queries bekijken

[Verwijderd]

TheRookie schreef op woensdag 24 mei 2006 @ 20:51:
't is een heel voor-de-hand-liggende vraag; maar dat oude boekhoudpakket gebruiken is geen optie ?
Al is het tijdelijk, dan kan je nog steeds met de profiler de door het pakket gegenereerde queries bekijken

De queries zitten in de database, maar die geven niet de informatie die ik wil hebben. Daarbij is het met de handgemaakt en is het niet meer bruikbaar op dit moment. Daarnaast wil ik graag de informatie uit de MySQL server halen en niet uit de MSSQL server halen. De clients mogen niet al te veel belast worden.