29. december 2004 - 09:40Der er
54 kommentarer og 2 løsninger
Access og Kalender
Hej
Jeg har i Excel lavet en aftalekalender (skabelon) med tider 08:00 - 16:30 med ½ timers opdeling og et frit felt under hver ½ time. Det er meningen at man skal have mulighed for at booke aftaler ca 3 måneder frem. Data til Kalender-skabelonen skal skrives til og læses fra Access. Nu kommer så problemet:
Hvorledes kan tabellerne til opsamling af data konstrueres. Som jeg ser det drejer det sig jo om tusindevis af felter til opsamling af data - og det er jo nærmest et uoverskueligt projekt at gå i gang med. Hvorledes kan SQL koden (afviklet fra Excel) selv konstruere et manglende felt i Access.
I dette særtema om aspekter af AI ser vi på skiftet fra sprogmodeller til AI-agenter, og hvordan virksomheder kan navigere i spændet mellem teknologisk hastighed og behovet for menneskelig kontrol.
Prøv som udgangspunkt at sammenkæde din Excel fil med Access.
Åbn en ny tom Access database og i menuen Filer > Hent eksterne data > Sammenkæd finder du din Excelfil og sammenkæder. Excel vil nu blive hentet ind i Access som en sammenkædet tabel.
Hvorfor i det hele taget arbejde i Excel? For mig at se, er det en typisk databaseopgave, så hvorfor skrive til / og læse fra Access, kan spørgeren give nærmere oplysninger, vil det være nemmere at give et forslag.
-->mugs: Hvorledes kan det du foreslå hjælpe? -->rbj fp: Den tabel konstruktion du foreslår hvorledes skal den "linkes" til alle de andre tabeller og i øvrigt drejer det sig om mange "konsulenter" der hver skal have egen kalender.
--mugs: Det primære arbejde er den konsekvens (ikke nødvendigvis god) af at jeg har lavet en del Excel koder men kun lidt i Access - jeg er da ellers fuldstændig enig! Men jeg anvender Excel som en "fremviser" af data fra access.
Det kommer jo meget an på hvilke tabeller du har med i din database.
hvor mange er mange???
For man kan jo lave flere forskellige løsningerne:
Den ene skal der bare tilføjes et konsulentID på tabellen, sådan at man kan identificere hvilken konsulent en given post drejer sig om. Alternativt kan man lave flere tabeller(1 for hver konsulent) og have en global list med tabelnavn, hvor så først slår op i den globalle liste og henter navnet på den tabel man ønsker at aflæse data fra.
Igen Det kommer jo lidt an på hvor meget data du regner med at der skal puttes i databasen. Hvis du regner med at hverdag skal alle konsulent have deres data fyldt ud, så ville jeg anbefale løsningen med global liste
-> Det her illustrerer vist meget godt hvorfor jeg ikke anvender access med mindre jeg er nødt til det (som nu). Kan du kort fortælle hvilke felter der skal placeres i databasen? --> Jeg har forsøgt at sammenkæde excel og access men det er vist ikke så enkelt idet Excel bl.a. anvendes til præsentation af data og derfor er forsøgt opsat pænt fremfor ideelt.
Altså i globallisten: konsulentID (telefonnr) Datatabellen: KonsulentID, Dato, Tidspunkt, Tekst (men den konstruktion) giver vel ikke et tekstfelt for hver ½ time?
"Jeg vil anvende flere datatabeller. faktisk 1 for hver konsulent...."
Det er vel ikke nødvendigt. Der kan laves forespørgsler der udvælger data for hver enkelt konsulent.
Skal databasen ligge på et netværk, kan der laves front-end, hvor konsulentens id er programmeret på forhånd i forespørgslerne. Disse front-end kan ligge på arbejdsstationernes C-drev for at spare netværkstrafik.
Mugs > Det er rigtig nok, men hvis vi antager at der kommer til at være de nævnt 30-50 konsulenter og hver dag bliver flydt godt ud, så kan det komme til blive en enorm datatabel, og det er sq ikke alt for godt i en access database(Læs: langsomme queries) og det er netop det jeg gerne vil undgå via det alternative løsnings forslag.
Mit forslag er at du har en tabel : GLOBALLISTE med flg. felter ID , KONSULENTID , TABELNAVN (auto) , (KENDES i forvejen) , Denne bygges
og for hver entry i denne tabel skal der bygges en Tabel som har samme navn som TABELNAVN... Dette er en større proces, men det hele kan laves via vba.
rbj fp > Vi skal så vide om det er hver enkelt konsulent der skal eksporteres til Excel. I bekræftende fald, skal der så laves en eksport for hver enkelt konsulent.
Derfor hælder jeg mere til den løsning, at samle alle konsulenter i en enkelt tabel for at eksportere dem samlet. Tabellen bliver stor men i det lange løb tror jeg ikke på løsningen med en tabel for hver konsulent.
mugs > Jeg ved at bare at store tabeller og access aldrig har været godt. Hvad er det ved løsningen med flere tabeller som du ikke tror på. Det anvendes jo ofte ved en specialisering i EER?
Det her er da vist en diskussion for eksperter!! Jeg er "desværre" nødt til at køre ud for at kigge efter en ny bil til fruen! Hvis det er ok vender jeg tilbage senere! vh Steen
OK. rbj fp > Jeg ingen dåelige erfaringer med store tabeller, heller ikke med mange mindre. Men når det drejer sig om at eksportere til Excel, mener jeg at een stor er at foretrække frem for flere små.
ja.... begge løsninger vil virke. Og selvfølge kan man jo anskue det ud fra synspunktet om at alle konsulenter skal have de samme typer af oplysningerne gemt, og derfor kunne man bruge en samlet liste. Men jeg tror på at hvis der komme mange poster, virkelig mange poster så er flere mindre en bedre løsning.
OK - Vi er ikke enige, men lad mig slutte denne diskussion med en enkelt kommentar:
Access er ikke begrænset af antal poster som Excel er. Access er kun begrænset af den samlede størrelse af databasen. Jeg har som et forsøg engang lavet en database med over 1 million poster, og det fungerede perfekt. Det er klart, at antallet af poster indvirker på databasens hurtighed men man kan jo ikke få alt her i livet.
If the data is the same as is the case with having more than one consultant then I see NO point in having the data in multiple tables. Its going against the principles of ralational databases. And if indexes are used correctly then performance should be no issue.
Det lyder til at der er flertal for samle data i en tabel. Hvorledes skal felterne så se ud (jvf det jeg har skrevet): KonsulentID, Dato, Tid, Text etc
Den er designet som en "papir" aftalekalender hvor man f.eks. kan anbringe ens navn øverst på kalendersiden. Øverst i Excel findes et felt med Konsulentnavn, og Tlf (konsulentID) men ikke i en separat kolonne.
Jeg hælder mere og mere til den løsning der hedder:
Skrot alt, og lav det i Access - Der er ingen grund til at benytte Excel. Hvis der endelig er brugere der absolut vil se det i Excel - Så lav en eksport.
Dette er en opgave for Access kun Access og ikke andet end Access.
Ja mugs - det har du sikkert ret i MEN kalenderen er en del af en større løsning som fungerer fint på den beskrevne måde (uden hastighedsproblemer) så det tror jeg ikke er aktuelt!
hvis du læser det du har stående i kolonne op i en streng i vba, og derefter
dim temp as string: right("din oplæste streng", 8) (p.s. det er ikke sikkert at syntaxen er helt sådan kan ikke lige huske det) men jeg vil dog oxo give mugs ret i at løsningen nok er lettere at lave i ren access.
Hej og godt nytår til jer alle. Det går planmæssigt med Kalenderen men mangler fortsat en del arbejde. Jeres hjælp var dog forudsætningen for at nå så vidt. Hvis du svarer rbj_fp så synes jeg at i deler point - er det ok med jer?
OK - Du vender blot tilbage, hvis du har behov for yderligere hjælp. Jeg kan sende dig en lille db, der viser forskellige muligheder for integration mellem Access og Excel, blot læg din e-mail.
Der er ikke noget i vejen for, at du kan programmere Excel i Access. Som du ser af et af eksemplerne, sætter jeg anvendte kolonner i Excel til den korrekte bredde (Usedcolums.Autofit eller noget i den stil), du kan selv prøve videre ved at indspille en makro i Excel, og derefter paste relevant kodelinie ind i Access. Så begynder det først at blive sjovt.
Ja det er også den beskrevne metoder jeg ofte anvender - det er meget lærerigt. Men af og til har man behov for lidt "igangsætter ydelse" fra mere kompetente programmører :0)
Det var så lidt.... ved flere problemer, så bare skriv
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
