nieuw veld met verwijzing naar bestaand veld

Status
Niet open voor verdere reacties.

snb

Verenigingslid
Lid geworden
12 jun 2008
Berichten
19.664
Ik maak een nieuw date/time veld aan.
Daarin wil ik verwijzen naar een bestaand veld 'Time'.
Het enige verschil is, dat het Time veld op minuuut-nivo (dd-mm-yyyy hh:mm) is en ik het nieuwe veld op uur-nivo wil formatteren (dd-mm-yyyy hh).
De eigenschap 'Default Value' zet ik op =[Time]

Als ik van Designmodus naar Datasheetview wil zegt Access dat het veld Time niet wordt herkend in de defaultvalue.
Hoe los ik dit op ?

Bij voorbaat dank.
 
Afhankelijk van de versie van Access die je gebruikt zou je het nieuwe veld als Berekend kunnen definieren.
Dan kan je opgeven dat [Time] gebruikt moet worden.

Succes
 
Nieuwe veld weggooien; dit soort zaken (afhankelijke velden) regel je met queries. Berekende velden zijn voor dummies :d.
 
Beiden bedankt.
Inmiddels had ik de 'berekend veld' optie ook gevonden.
En het werkt nog ook !

Maar ik mag er blijkbaar niet van iedereen gebruik van maken.:(

Ik ga de query-opties onderzoeken om weer een beetje in de achting te kunnen stijgen.

U hoort nog van ons.
 
Laatst bewerkt:
Berekende velden zorgen ervoor dat je tabellen niet meer compatibel zijn met andere (database)systemen. Bovendien vind ik ze volslagen nutteloos, omdat je, als je meerdere afhankelijke berekeningen nodig hebt, alsnog een query moet maken. Ik vind ze niets toevoegen aan de bestaande technieken. Maar gebruik ze gerust, als je er wat aan hebt :).
 
Zo bang ben ik niet uitgevallen.
Maar met een database van 130 Mb leidt een query als snel tot een verdubbeling van de omvang ? Ik wil hem/haar als externe bron voor een draaitabel in Excel gebruiken.

Wellicht zie ik wat over het hoofd ?
 
waarom zou een query de grootte verdubbelen? Het enige dat wordt opgeslagen is de query instructie = de SQL tekst + het query plan. Dat zijn hoogstens een paar kilobytes. Telkens je de query opent wordt de SQL instructie terug uitgevoerd volgens het opgeslagen plan. Ten ware dat je de query instructie hebt aangepast, dan wordt de eerste keer dat je de query terug uitvoert een nieuw plan opgesteld.
 
Ik wil hem/haar als externe bron voor een draaitabel in Excel gebruiken.
Des te meer reden om geen berekend veld te gebruiken. Zelf nooit gedaan, maar ik vermoed dat dat niet eens gaat lukken met tabellen met berekende velden. Met een normale query met berekeningen is dat geen enkel probleem, en zoals Noella al zei: voor de grootte van de db maakt het geen moer uit.
Al snap ik dan weer niets van het verhaal over een ‘query plan’. Voor vakantieplannen mag je me wakker maken, query-plannen mag ze houden :). Een query is een opgeslagen database instructie, meer niet. En die kan je uitvoeren of niet. Met of zonder plan :d.

Overigens kan je de berekening zelfs buiten je db houden, en in Excel doen. Wellicht is dat nog sneller ook. Leuke test, met zoveel records!
 
Een query plan (of query uitvoeringsplan) is de volgorde van stappen die gebruikt worden om de gegevens op te vragen in een SQL relationeel database management systeem. Ook Acces maakt achter de schermen gebruik van deze uitvoeringsplannen die opgeslagen worden bij de eerste uitvoering van een query. Daarom is een query sneller als je deze opslaat na de eerste uitvoering: dan wordt het plan mee opgeslagen en moet bij een volgende uitvoering geen nieuw plan meer opgesteld worden. In deze video kan je zien hoe je in Access dit plan kan bekijken en gebruiken om je queries te versnellen: https://www.youtube.com/watch?v=nJe5dP1ufZs, met wat meer uitleg in deze paper: https://nolongerset.com/jetshowplan-a-primer/.
Dus zonder plan gaat niet echt, want zonder plan werkt de query niet.
 
In mijn Access heet dat planning.
Inmiddels de query ontwikkeld om uit een bestand met 770k records een aantal velden en een in de query gedefinieerde Expr1 ('berekend veld) te halen.
Het klopt natuurlijk dat de querydefinitie nauwelijks ruimte vergt.

In Excel een draaitabel aan deze query gekoppeld.
Werkt als een zonnetje.
Geldt ook voor de daaraan gekoppelde grafiek.

Nu nog een aantal andere query-definities maken om in Excel als keuzen op te nemen, zodat die ene draaitabel aan steeds een andere query gekoppeld kan worden v\ia de eigenschap .commandtext .

Dank voor het meedenken.

Wordt vervolgd
 
Dus zonder plan gaat niet echt, want zonder plan werkt de query niet.
Straks ga je ons ook nog vertellen dat er zonde water geen leven op aarde mogelijk is….
Niemand, ook jij niet, kan een ‘query-plan’ in Access maken; dat is onderdeel van de onderliggende techniek. Mij ontbreekt de tijd en de wil om mij daarin te verdiepen. Ik heb genoeg aan kennis om snelle queries te maken :).
 
En dat is de reden dat ik betaald wordt om aan database tuning te doen en jij niet ... :D :p :D :d
 
Huidige stand:

1 Csv bestand 87 Mb
1 database (Access), gekoppeld aan het csv-bestand
7 Queries voor 7 parameters
Access-bestand 500kb
1 Excel-bestand met 2 draaitabellen, gekoppeld aan dezelfde Query in het accessbestand
7 Optionbuttons die het bestand aan een andere Access-query koppelen en de draaitabellen aktualiseert.

Waarneming:
- het aktualiseren verloopt langzamer bij een aan Access (van 500 kb) gekoppeld csv bestand , dan bij een ingelezen tabel in Access (131Mb)
- voordeel van deze constructie: iedere wijziging in het CSV-bestand komt via deze omweg in Excel terecht zonder iets in Access of Excel te hoeven wijzigen.

Ik ben benieuwd naar verdere 'database tuning'.
 
Bij een gekoppeld bestand kan je weinig doen. Bij natieve database tabellen kan je een grote winst halen door de juiste indexen aan te maken.
 
Als ik dat probeer in een tabel in de Database zelf, dan krijg ik de melding, dat ik in het register de MaxLocksPerFile moet verhogen.
Verhoging van 9500 naar 12500 geeft geen verbetering.
Ik heb geen idee welke omvang dan wel gepast zou zijn.
Overigens komt slechts 1 veld voor indexering in aanmerking; de overige bevatten allemaal unieke meetwaarden.
 
De verhoging lijkt mij niet significant veel groter. Ik zou grotere stappen proberen, als je daar mee wilt experimenteren. Een tabel met één indexeerbaar veld hoef je natuurlijk niet verder of anders te indexeren.
Dat een native tabel beter werkt dan een gekoppeld csv bestand, hoeft uiteraard geen betoog. De vraag is niet zozeer óf er een verschil is, maar of dat verschil voor jou werkbaar genoeg is of niet. Tabellen elke keer opnieuw in Access inlezen kost immers óók tijd.
 
Indexering heeft niets te maken met unieke waarden, de belangrijkste index de PK ligt zelfs op een veld dat uniek moet zijn. Indexen leggen ook geen extra locks, maar helpen om minder locks te hebben: hoe sneller een query werkt, hoe vlugger de locks worden vrijgegeven. Om te bepalen welke indexen:
- fast gain: indexeer alle foreign keys
- voor de rest: kijk welke criteria gebruikt worden en leg daar de nodige indexen, enkelvoudig of meervoudig, afhankelijk van je queries
- vraag het query plan op: kijk welke indexen gebruikt worden en pas eventueel je indexen aan naargelang het query plan

Hierbij een deel van een document dat ik jaren geleden voor een specifieke cursus heb gebruikt maar misschien nog een paar bruikbare tips bevat:
 

Bijlagen

  • index.zip
    141,9 KB · Weergaven: 16
@Noella,

Als ik die locks melding krijg in de wizard tabel-analyse, nadat ik heb aangegeven voor welk veld een aan dat veld gekoppelde hulptabel moet worden aangemaakt, dan denk ik dat Access het beter weet dan jij en ik.
 
Ik weet het zeker niet beter, want ik ken je applicatie niet. Maar neem maar aan dat jij het beter weet dan de Access wizards,:) . Als je op die wizards vertrouwt krijg je niet echt een goede applicatie.
Maar dan heeft dit zeker niets met indexen te maken.
 
Maar neem maar aan dat jij het beter weet dan de Access wizards,:). Als je op die wizards vertrouwt krijg je niet echt een goede applicatie.
Dat klopt voor een heel groot deel zeker. Ik vermoed dat een aantal Access onderdelen, zoals de wizards, worden ontworpen door Microsoft medewerkers die weddenschappen hebben verloren, of als ontgroeningsklus. Of als wedstrijd om te kijken welke programmeur het slechtste onderdeel kan maken, en er mee weg komt :).
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan