Overfør

you will need to do this in a form.
You should do it on the forms AFTER update event to make sure that the reocrd is actually saved.
then you could use docmd.runsql "INSERT INTO tabel2(ID) VALUES ( Me.ID & ")"

or something like that

docmd.runsql "INSERT INTO tabel2(ID) VALUES (" & Me.ID & ")"

Tilføjelse til spørgsmålet:

Denne her værdi, som bliver trukket fra tabel1 til tabel2 har et antal login fra flere forskellige tabeller (1 for hver måned). Alle måneder hvor ID 26 har været logget ind, skal ligges sammen i et felt2 - antallogin. Jeg har fået den til, at ligge tallene sammen, MEN.

Den ligger tallene sammen så linie 1 i januar bliver lagt sammen med linie 1 i februar - forkert.

Det skal være ID 26 i januar ligges sammen med ID 26 i februar.

Hvordan?

docmd.runsql "INSERT INTO tabel2(ID) VALUES (" & Me.ID & ")"

Hvordan gør jeg ved flere tabeller? (Hver måned)

? Not quite sure I understand!
You are saying that there can be more than one ID (one for each month) which have to be added together BEFORE the result (sum) gets put in table 2! Or is it the actual NUMBER of times which you want?

You can use DSum to give tou the SUM of all fields where ID = 26 or you can use DCount to give you the number of records with ID = 26

xxx> concerning the other question I was looking at for you, hope it doesnt give you too many headaches in finding another solution!

No!

Tabel:Januar
ID            Antal login
26              3
3553            4
324            4

Tabel:Februar
ID            Antal login
324            4
26              6

Tabel:Samlet
ID            Antal login
26              9 (januar+februar)
3553            4 (januar+februar)
324            8 (januar+februar)

De bliver listet i hver 'måneds'-tabel efter hvem der først logger ind. Derfor kan man fx. ikke sige linie1+linie, men ID 26 + ID 26!

Det andet spørgsmål! Nej, dem der skal bruge databasen vil alligevel ikke kunne bruge den før om senest et halvt år, vil jeg regne med!

and I can also guess that there is one for march too and so on?

xxx I think you should consider designing your tables in another way.  The approach you are taking at the moment is going to give you problems!

What problem do you mean?

If I understand the question correctly you ntend to create a NEW table for each month. If that is correct then it means that you have to alter ALL queries etc, which have to for example make calculations from these tables. This isnt the normal way to do things! Once the application is made, it should NOT be necessary to ALTER the design (add new tables).

You could alter your table so that it contians a field for the month, and also maybe one for the year. Then you just have to add logins where ID = 26 and maybe for the same year

Du skal da lave en tabel-struktur, som denne:

Tabel: LogIn
Måned (langt heltal i formatet "yyyy-mm")
ID
Antal

Så kan du bare forespørge på år og måned i forespørgsler...

I have these fields:

ID kundenr antallogin antalkoeb samletkoeb

Jeg skal kunne se alle data for hver måned og samlet for et helt år - som sagt.
Hvordan ville du da sætte det sammen i kun en tabel?

Hi proaccess>I agree :o)

xxx You can have a table containing th einformation and then yoiu make a query to sum grouped by ID year

Jeg tror jeg holder fast ved, at oprette en tabel for hver måned - da jeg ikke helt forstår hvad det er I mener. Jeg har brug for et mere konkret eksempel - det er jo en db der skal bruges på en .asp-side.

Hvis du forestiller dig også at registrere dato-info... så vil din tabel se sådan ud:

ID Måned kundenr antallogin antalkoeb samletkoeb

Så vil du kunne lave forespørgsler som:
Vis totaler for februar 2002 - SELECT Kundenr, Sum(antallogin), Sum(Antalkoeb), Sum(Samletkoeb) FROM tabelNavn GROUP BY Kundenr WHERE Dato Between #02-01-2002# And #02-28-2002#;
Vis totaler for hele 2002 - SELECT Kundenr, Sum(antallogin), Sum(Antalkoeb), Sum(Samletkoeb) FROM tabelNavn GROUP BY Kundenr WHERE Dato Between #01-01-2002# And #12-31-2002#;

HVIS DU HOLDER FAST VED 1 TABEL PR MÅNED, SÅ SKAL DU GØRE DET PR. ÅR/MÅNED, ELLERS GÅR DER GED I DET VED ÅRSSKIFTE...

DATABASEN SKAL JO VIDE OM DET ER JANUAR 2001 ELLER JANUAR 2002 !!!

Nej, dit eksempel virke forståeligt - proaccess!

Det der Sum(Samletkoeb)? Skal det være et udtryk?

FROM tabelNavn GROUP BY Kundenr WHERE Dato Between #02-01-2002# And #02-28-2002#;

Hvor vil du sætte det ind?

Sum() er rigtig nok udtryk...

Du skal gruppere din forespørgsel, klik på knappen grupper, og vælg grupper efter ud for feltet kundenr, og derefter sum for antallogin, antalkoeb og samletkoeb. På feltet Dato vælger du hvor, og angiver fra og til-dato på kriterielinien...  Det er kun de ovenstående felter, du skal have med i forespørgslen.

Jeg forstår dig ikke helt mht. grupper knappen, hvor finder jeg den?

Feltet dato? Hvor kommer det fra - mener du dermed måneden?

Du vil vel have en tabel for hver måned?

Mit udgangspunkt er een tabel for alle måneder, hvor du registrer måned, kunde og øvrige oplysninger...

På denne tabel kan der så laves de ovennævnte forespørgsler, som summerer data på tværs af måneder...

Gruppering (Totaler) får du frem ved at klike på knappen med sum-tegnet... (Det ligner et M, som ligger ned)

proaccess - er det også sådan at du har forstand på .asp-programmering?

For registrere det automatisk dato, og kan sortere herefter ved et login?

Antal køb skal ligesom antal logins være gældende for hver måned, samt et total køb for hver måned.

Vil det ikke kræve tre slags felter: 1- januar"antallogin" 2- januar"antalkoeb" 3- januar"samletkoeb" osv.

Jeg tror lige vi skal spole lidt tilbage, jeg står lige og snakker med en anden, og det er ved at blive lidt forvirrende.

>xxx: Kom du videre med dette, og kan vi få spørgsmålet lukket??

?

Lukket

Det virker IKKE særligt befordrende for min lyst til at hjælpe dig i fremtiden, at du sådan "bare" tager pointene selv...
Både Tery og jeg har lagt et stort arbejde i at hjælpe dig, og det må siges bare at være lidt unfair, totalt at ignorere dette...
Der var RIGELIG mulighed for dig til at komme med yderligere kommentarer hvis du ikke forstod vores løsningsmodel, men sådan skulle det jo altså ikke være...
** SUK **