Data uit 2 tabellen in Query plaatsen werkt niet

Status
Niet open voor verdere reacties.
O

omewillem

Gebruiker
Lid geworden
4 jun 2012
Berichten
41
Goedemorgen,

ik heb een aantal vragen: in de bijlage heb ik een bestand geplaatst waar het om gaat.
de eerste vraag is: is het slim om alle verzameldata in een tabel te houden om die in een formulier weer te geven, of is het verstandiger om de verzameldata te verdelen onder meerdere tabellen, bv alle remarks( dit is kale tekst om afwijkende gegevens te noteren) in een tbl_remarks te plaatsen. als ik dat doe dan kan ik niet het id van het record in tbl_Calls koppelen aan het id uit de tbl_remarks, ik krijg dan een foutmelding..

de tweede vraag is, is het slimmer om een formulier van een Query of van een Tabel te maken?

alvast bedankt voor jullie tijd,

groet

wim
Bekijk bijlage Posten.rar
 
Ik kan nu even niet bij een computer dus ik kan niet in je database kijken maar een algemeen antwoord hebt je allicht al verder.

Vraag 1: data moet je altijd gestructureerd opslaan op basis van gegevensafhankelijkheid. Hoe je dat doet is vastgelegd in het Normalisatieproces. Dat moet dus leidend zijn bij het opzetten van je tabellen. Gemak(zucht) mag dus nooit een rol spelen. Je moet altijd kijken naar welke gegevens bij elkaar horen en van elkaar afhankelijk zijn.

Vraag 2: lood om oud ijzer als je het mij vraagt. Ik maak formulieren op basis van tabellen en queries. Ook hier geldt: afhankelijk van wat je aan het doen bent.
 
m.b.t. vraag 2: het openen van formulieren op basis van queries duurt langer dan op basis van tabellen, dus performance van je applicatie kan mogelijk een rol spelen.
 
Bospeen zei:
m.b.t. vraag 2: het openen van formulieren op basis van queries duurt langer dan op basis van tabellen, dus performance van je applicatie kan mogelijk een rol spelen.
Klik om te vergroten...
Waar haal je die wijsheid vandaan? Ik zou eerder het omgekeerde hebben beweerd...
 
OK, laten we het eens over je db hebben. Dan gaat het voorlopig dus even om de tabel [tbl_Calls]. Wat als eerste opvalt: je hebt daar de velden [Status] en [Agent]. Die heb je gedefinieerd als Memo. Dat is met afstand het meest onhandige veld dat je daarvoor kunt gebruiken. Om te beginnen: een memoveld kan 64000 tekens bevatten. Ik kan mij niet voorstellen dat je er ooit meer dan 5 nodig zult hebben om een Agent of Status vast te leggen. Want dat is gelijk het volgende punt: voor die twee velden heb je koppeltabellen gemaakt: [tbl_Agent] en [tbl_Status_of_Vessel]. Die velden moeten dus numeriek zijn, zodat je ze kunt koppelen aan de koppeltabellen.

Iets vergelijkbaars met de velden [Arived from] en [Sailed to]. Al zijn dit nu tekstvelden. Maar ook hiervoor heb je een koppeltabel. Nog zoiets: jij hebt aparte tabellen gemaakt voor Sailed_To en From, maar dat is natuurlijk onzinnig; we hebben het hier over havens in landen, neem ik aan, en het maakt voor een haven totaal niet uit of een schip daar nu aankomt of vertrekt: de haven blijft exact hetzelfde. De entiteit haven is in beide gevallen hetzelfde, ergo: havens sla je op in één tabel. Dat je die tabel in een andere tabel twee keer gebruikt: so what?

Het veld [Vessel name]? Als elk schip vaker terugkomt in je db, dan moet dat ook een aparte tabel worden. Kun je gelijk alle kenmerken van dat schip ook vastleggen. [Ankerplaats]? Je hebt een tabel, verwijs dus met een numeriek veld naar de sleutel van die tabel. De velden [Captains Name] t/m [Captains E-mail]: hoort een kapitein bij een schip, zet het dan daar bij. Ik kan mij voorstellen dat kapiteins nog wel eens wisselen, dus een aparte tabel zou beter zijn. Maar: als een kapitein vaker gebruikt wordt, horen deze gegevens absoluut in een eigen tabel.

Het veld waar je vraag over ging ([Remarks]) is de makkelijkste: die hoort gewoon thuis in deze tabel, en dus absoluut niet in een aparte tabel.
 
ok, hoe die tabellen memovelden zijn geworden snap ik niet, in het origineel staan ze gewoon als numeriek...
maargoed, ik heb je advies overgenomen, werkt perfect nu.

met vriendelijke groet,
Wim
 
HTML: 
Waar haal je die wijsheid vandaan? Ik zou eerder het omgekeerde hebben beweerd...

Ik werk met tabellen met veel records, soms enkele miljoenen. Een formulier openen op basis van zo'n tabel (met indexen) gaat vele malen sneller dan op basis van een query hierop (zonder indexen). Dat is mijn ervaring, soms is de performance zelfs zo belabberd dat querybasis niet kan: het runnen van de query op zich vraagt dan teveel tijd.
 
Een query gebruikt dezelfde indexen als de onderliggende tabel, dus dat mag helemaal niks uitmaken voor de performance. Wat wél enorm scheelt, is als je geen pure SQL in de query gebruikt, maar VBA calls. Dat houdt inderdaad bij grote tabellen stevig op. Maar dat is eerder een kwestie van de query eens tegen het licht houden, en niet van een snelheidsprobleem door de query.
 
ik heb het probleem nog steeds niet opgelost

Goedemorgen,
ik ga het nu proberen beter uit te leggen, ik hoop dat jullie mij snappen:D
in de bijlagen heb ik het bestand toegevoegd waar alles om draait, dit is een uitgeklede versie van het origineel, dat is nu bijna klaar:thumb::thumb:

het volgende wil nog steeds niet lukken:
bij het openen van : "frm_main_tabs" (Gegevensbron Querry_Main) kan je naar het tabblad "contact details" gaan.
hier heb ik een tekstvak "vessel email", hier wil ik graag gegevens in hebben die uit "tbl_Vessel_Data" moeten komen, maar wel met de gegevens die bij een Vessel ID horen.
ik kan de "tbl_Calls" vullen door een nieuwe Call aan te maken via de New Call button op het "frm_main_Tabs" , die vult de Querry dan weer.
het zelfde geld voor: "frm_Edit_Data" ( via de knop Vessel info) , hier zou de lijst onder tabblad Vesselinfo opgehaald moeten worden uit "tbl_Vessel_Data" maar wel de data van het schip dat in het tekstvak Vessel name staat.
ik heb een relatie aangemaakt, maar ben nu zo aan het knoeien en prutsen zodat ik door de bomen het bos niet meer zie, is er een duidelijke en begrijpelijke manier voor mij om dit probleem op te lossen?

alvast bedankt voor de hulp

gr

wimBekijk bijlage Temp.rar
 
Laatst bewerkt:
Als je er een zip file van kan maken, kan ik er zo wel even naar kijken. Anders wordt het vanavond.
 
Ik heb het omgekeerde :). Maar zippen is toch een standaardfunctionaliteit van Windows? Rechtsklikken en <Kopieren naar> --> <Compressed zip foder>. Vreemd dat ze dat er uit slopen...
 
En toen was ik zo druk, dat ik er alsnog geen tijd voor had. :) Maar ik kijk er nu even naar.
 
En nu even uitleggen wat de bedoeling is, want ik zie in je tabel wél een veld [vessel email], maar op je formuler niet. Daar zie ik wel een tekstveld [Vessel name], maar geen keuzelijst. En dat is de manier om de velden uit de tabel [tbl_Vesseldetails] op je formulier te laten zien. Je zet dan een extra tekstveld op je formulier met deze formule als Besturingselementbron: =[cboVessel].[column](4)
 
dank je OctaFish,
dat is precies wat ik bedoel, die =[cboVessel].[column](4) kreeg ik niet voor elkaar, dus eigenlijk hoefde ik alleen maar te vragen hoe die formule van het besturingselementbron opgebouwd is:D:D
ik heb hem nu wel aan de praat, nogmaals dank voor uw tijd en moeite
gr

wim
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan