DLOOKUP - eller lign. funktion

Det har ikke noget med Dlookup at gøre... Du skal bare lave din forespørgsel som beskrevet og derefter evt. lave en update query der opdatere din tabe 1 med værdierne i tabel 2 på prisfeltet.

Hvorfor vil du egentlig opdatere tabel 1 ??? du kan jo bare bruge bruge relationer såfremt du skal bruge resultatet dybere inde i database.
Evt. kunne du lave en UNION query.

Jeg er til dels enig med region vedr. relationer. Men det kan dog sagtens laves ved en Dlookup. Koden er afprøvet i Access97 og fungerer fint. Me refererer til den aktive formular, og er beregnet til numeriske felter:

Dim intsearch As Long, intsearch1 As Long
intsearch = Me!Længde
intsearch1 = Me!Bredde
Me!Pris = DLookup("[Pris]", "Tabel2", "[Længde]=" & intsearch) And DLookup("[Pris]", "Tabel2", "[Bredde]=" & intsearch1)

Husk, at Dlookup funktionen skal skrives på een linie, og ikke som her skilles ved "And".

>Mugs: skulle det ikke være...

Me!Pris = DLookup("[Pris]", "Tabel2", "[Længde]=" & intsearch & " AND [Bredde]=" & intsearch1)

MUGS :

Grunden til at jeg skrev at det ikke havde noget med Dlookup at gøre var fordi Kjar75 ikke nævner noget om en formular.... Jeg er enig i at man selvfølgelig her kan lave Dlookup. MEN....
Er man ikke bevandret i Dlookup og dennes "langsommelige" opdatering kunne man jo lave en query som jeg nævner og dermed basere sin formular på denne.

Så er det bare at trække felterne ned i formen fra feltvælgeren..

:-) ( det er vel ikke for ingenting vi er "gæve" sønderjyder )

If you ask me I would re-design the tables!

Is the Brede and Længde in table1 the same as in table2 or is it possible to purchase other lengths where the price is calculated there after?

IF you can ONLY purchase fixed sizes then I would have an ID for each size in table2 and then in table1 I would store the ID and the price. Doing it this way I could always see which item was purchases and to what price.

proaccess > både og. Jeg har lige afprøvet begge koder, og de fungerer fint i Access97. Jeg vil medgive dig, at din er mere korrekt, idet den er mere elegant og simpel.

region > Det kan jo godt være jeg tager fejl, men jeg har simpelthen antaget, at vi taler om en formular.

Mugs og Proaccess-> Det er altid mest korrekt at foretage så få DLookup's som muligt. Mugs's løsning tager således dobbelt så lang tid (ca) som Proaccess'es. Har vi store datamængder eller et langsomt netværk, så kan vi snakke flere sekunders forskel.

thomas > Enig, men det er vel også det jeg skriver både i mit svar 8/4 og min kommentar til proaccess 9/4.

Nu mangler vi jo en kommentar fra kjar75.

Hvis det er meningen at man skal kunne få div. rabatter eller prislisten jævnligt ændres, passer tidligere ordre jo ikke længere.
vha en opdaterings foresp. sikre man at kun 'tomme' priser i tabel1 opdateres:
UPDATE tbl1, tbl2 SET tbl1.Pris = [tbl2].[pris]
WHERE (((tbl1.bredde)=[tbl2].[bredde]) AND ((tbl1.længde)=[tbl2].[længde]) AND ((tbl1.Pris)=0 Or (tbl1.Pris) Is Null));

Niels

nih > Ja en kommentar fra kjar75 vil være velkommen - hvis han (hun) ikke er blevet helt rundforvirret af mulighederne. Det er jo en af de charmerende ting ved emnet, at der er så mange måder at gøre tingene på. Bedst som man tror, den dybe tallerken er opfundet igen, kommer en bruger med et nyt forslag, der er mere elegant end det forrige.

Dit svar ang. ændring af prislisten er selvfølgelig noget, der skal tages i betragtning i en samlet løsning. Jeg opfatter tabel1 som en tabel, hvori nye salg indtastes med gældende priser, og der vil derfor aldrig være tomme proder i denne tabel. Det er derfor ikke nødvendigt at opdatere denne. Tabel2 skal naturligvis opdateres med den altid gældende priser.

Hvis vi går lidt videre skal vi vel også tænke på historikken m.h.t. evt. momsregnskab, eller blot en oversigt over, hvad de enkelte kunder har købt. Så skal vi have fat i en 3. tabel der udelukkende lagrer køb til senere brug.

Og sådan kan vi blive ved!

Hej allesammen - og tak for alle svar :-)

Ja, jeg må indrømme at jeg er en smulle "rundtosset" efter alle disse besvarelser...

Her er lidt ekstra info - for at specificere ovenstående debat...

Tabel.2 angiver priser i MANGE forskellige intervaller/kombinationer med brede og længde...

MEN - i tabel.1 (selve ordrelinien) vil der oftest blive indtastet en brede og længde som IKKE stemmer nøjagtig overens med tabel.2

Eks.
Tabel.1
Ønsket brede;længde = 115;110

Tabel.2 - de definerede priser ud fra mål
Brede  Længde  Pris
100    100      150
120    100      170
120    120      190

Og så fremdeles.... Data fra tabel.1 skal således søge efter den nærmeste værdi i tabel.2 !!!!

Mugs har fuldstændig ret mht historik / momsregnskab...
Når "prisen" er fundet FØRSTE gang, skal den "lagres" i selve ordren og gemmes... For priserne kan løbende blive ændret!!!

Hvis man herudover kan lave et ekstra felt til rabat vil det bare være perfekt !!!

Jeg er stadig ikke med på, hvor "formlen" skal stå henne, både i forespørgslen og/eller formular !!!

Håber i kan hjælpe mig et skridt videre efter ovenstående :-)

PS:
Da jeg tager på en kort ferie fra idag - og først kommer tilbage mandag 15/4 kan jeg desvære ikke svare på evt. spørgsmål.
Glæder mig dog til at komme tilbage og se, og i har flere indlæg som kan hjælpe mig i "mål"  :-))

God ferie.

Det burde vel være nok, at lave en knap på formularen, som fx. hedder "btnFindPris", denne kunne så finde mindste-prisen i tabel2, hvor brede og længde er lig med eller større en de angivne på på formularen... (i mit eksempel hedder felterne på formularen: Brede, Længde og Pris ligesom i tabellerne)

Private Sub btnFindPris_Click()
  If Me!Brede>0 And Me!Længde>0 Then 'står der noget i både Brede og Længde på formularen
    If Me.Pris<>0 Then 'står der en pris i forvejen?
      If MsgBox("Vil du overskrive den eksisterende pris?", vbYesNo)=vbYes Then
        Me!Pris=DMin("[Pris]","Tabel2","Brede>=" & Me!Brede & " AND Længde>=" & Me!Længde)
      End If
    Else
      Me!Pris=DMin("[Pris]","Tabel2","Brede>)" & Me!Brede & " AND Længde>=" & Me!Længde)
    End If
  End If
End Sub

på den måde kan priserne genberegnes, men udgangspunktet er at der trykkes på knappen ved ordreoprettelse, og at prisen dermed gemmes een gang for alle på selve ordren.

I STILL say that the databases should be redesigned! If each product has a unique ID then it is just a case of saving the ID and the CURRENT Price in table1 alomg with the length+width. Thats what RELATIONAL DATABASES is all about!
Why make this difficult?

Hej proaccess

Tusinde tak for svaret :-)

Din kode volder dog stadig problemer, når jeg indsætter en kommandoknap
med hændelsesprocedure iht din kode...

Fejlmeddelelsen kommer her...

"Dette Recordset kan ikke opdateres. (Fejl 3326)

Du har forsøgt at redigere data i et felt, der er bundet til et Recordset-objekt af typen snapshot. Felter af typen Snapshot i en Microsoft Jet-database kan ikke redigeres."

Jeg kan ikke lige overskue hvad der går galt :-((

Vil du prøve at indsætte funktionen/koden i db hvis jeg må maile den til dig ???

Mange hilsner kjar75

Du kan bare sende den på proaccess@hotmail.com

Thanks :-)

Den er hermed sendt...

Du skal "bare" basere din formular direkte på tabel1, og slette forespørgslen "PRIS", den er overflødig!

Jeg sender ikke basen tilbage, med mindre du beder mig om det... (det skulle være lige til at få retttet)

Så for satan... Det virker :-)))

Det er bare perfekt.....

Har dog en ekstra lille ting at tilføje !!

Der er et ekstra felt i begge tabeller kaldet TYPE som enten kan være "S eller K" !!!

Jeg har "viderebygget" funktionen til

Me!PRIS = DMin("[Pris]", "Tabel2", "Brede>=" & Me!BREDE & " AND Længde>=" & Me!LÆNGDE & " AND TYPE>=" & Me!TYPE)

MEN - mit prisfelt kan IKKE opdateres da værdien i feltet TYPE skal være et tal !!!

Kræver det en længere kode at klare denne problemstilling ??

Sidst men ikke mindst - jeg vil gerne uddele lidt point, og oprette dette spørgsmål med nye point !!!

Kan man oprette nyt spørgsmål - kædet til dette ???

Du kan ikke sannemkæde spørgsmål - men du kan referere til dette ved at indsætte et link.