Oprette felter via kode...

det lader ikke til at field objektet har en egenskab der hedder format - så spørgsmålet er hvordan man så gør det ?


Horus

Hej min gamle gude-ven :o)

Længe siden....

Er det stadig Access 97 vi snakker om?

Har du prøvet vha datadefinition-forespørgsler (som du jo også bare kan generere og kalde fra koden)

hejsa Thomas,

yeps - længe siden - håber alt står vel til.

Og ja - stadig gode gamle Access97 - jeg var ikke lige opmærksom på datadef. forespørgsler - så jeg har kigget lidt på det - men ak og ve - det lader til at være nøjagtigt det samme man kan (og ikke kan) med dem, som via \"ren kode\"....

Øv - men tak for forsøget.

Horus

P.S.

Du har ikke tilfældigvis en Office97 Pro og/eller en ODE 97 til salg, vel ?

horus>
when you create tables each field is given a specific data type. There is no data type \"Short Date\"! This is just a property for displaying the date in a specif format. In all cases the date is stored in the same way.
You can as Thomas says, make a query and here you can show the date field in any FORMAT you want.

Or in a field on a form (Access) you can set the format property to \"Kort DatoFormat\".
I also think this is possible in ASP too.

jeg er lige ved at have den Horus,

PS: Nej jeg har desværre ikke Office 97/ODE 97 til salg, beklager :o(

Ok, here it is:

    Dim db As Database
    Dim prp As Property
    Dim tdef As TableDef
    Set db = CurrentDb
    Set tdef = db.TableDefs(\"Test\")
    Set prp = tdef.Fields(\"NyDato\").CreateProperty(\"Format\", 10, \"Short Date\")
    tdef.Fields(\"NyDato\").Properties.Append prp


mvh
Thomas

I could understand it would be nice to specify the date format when creating a table/field via SQL but why do it in code? If I am able to do it in code then I would also thought I could just go into table design view and set the format there!! or is there something I am missing?

Horus? Er du der?

Terry-> Det gælder jo generelt! Du kan gøre alting manuelt. Ideen med VBA er jo at der er situationer, hvor det er en fordel at gøre det via kode. Tænk at du (nr 2 på Access-listen) spørger hvorfor man skal lave noget via kode, når man lige så godt kan gøre det mauelt!!!???

I dette tilfælde kunne det være, at man lavede et system, hvor brugeren selv skulle kunne tilpasse systemet efter sine egne behov. Dvs selv oprette de felter, som han finder interessante/relevante. Det kunne f.eks. være et datofelt.

Thomas - du er jo guld værd :-)

Har ikke prøvet det endnu, men det LIGNER noget der virker :-)

Jeg, var smuttet fra jobbet - derfor først svar nu...


terry og thomas:

Jeg skal have opdateret en backend fil ude hos en hel masse kunder, og den kan jeg jo ikke bare klare ved design-view :-)

Hygge og god jul

Horus/Daniel

Yes even I as (nr 2 på access-listen) like to keep things simple!
I suuspect that the alterations to the backend will have consequences for the frontend. Which, I suspect will mean a new updated frontend to all your customers. So I wouldnt even think about having the FORMAT of the date field in the backend, but in the actual field in the frontend.
And just out of interest, th eformat of the date field can be altered in the front end for a linked table!

terry,

Der er lavet en ny og (meget) forbedret frontend med en lang række funktioner som der slet ikke var tænkt på da den oprindelige backend i sin tid blev lavet.

Brugerne har mulighed for at købe en opdatering og dermed få den nye frontend - i frontenden laver jeg så en funktion der tjekker hvilken version af backend brugerne har, og opdaterer derefter backend så den indeholder alle nødvendige tabeller, felter og relationer.

Da brugerne godt kan modtage andre backends som de så skal \"koble\" deres frontend op i mod - af en række andre brugere, der kan have forskellige version af vores backend, så har jeg vurderet at det smarteste er altid at lade den nye frontend opdatere alle de backends den kommer i nærheden af så de er \"uptodate\". Der sker jo ikke noget ved at den opdaterede backend senere bliver koblet sammen med en gammel frontend... Den har jo ikke brug for de nye felter og er jo derfor ligeglad med om de er der eller ej....

Interessant er det dog at du mener at det ikke er smart at have datoformatet direkte i tabellen men i stedet defineret i de formular og rapport felter det benyttes i - er det korrekt forstået - det vil jeg da overveje om jeg er enig med dig i til fremtidige opgaver.

og tak for informationen om at man kan ændre format egenskaben for sammenkædede tabeller direkte fra frontend - det var jeg ikke klar over - men i og med at feltet alligevel skal tilføjes, så virker det på mig smartest at man i samme omgang tilføjer format egenskaben, i stedet for først at oprette feltet og dernæst ændre format egenskaben for den sammenkædede tabel/felt....

Men det er jo det gode ved programmering - der er tit og ofte mange forskellige løsninger til samme problem - og det er jo altid svært at vurdere om én er bedre end en anden - det kommer vel meget an på temperament og opfattelse, men det er da altid rart at høre andres meninger, så tak for det :-)

Horus

P.S.

Hvis I er nummer 1 & 2 på access listen - hvad er jeg så ?..... nr. 127.300.213,46 ? ;-)

Hej begge 2,

Som Terry rigtigt siger, så er den eneste fordel ved at definere format, inputmaske, defaultvalue m.fl. på tabelniveau, at det automatisk bliver overført når man laver nye formularer eller når man trækker felterne over på en formular.

Ellers vil formularens formattering, inputmaske og defaultvalue være den bestemmende. Så i dit tilfælde var det som sådan ikke nødvendigt at lave denne kode (men det var da interessant at finde ud af :o)

Det er faktisk en meget interssant tanke, det med at lade frontenden opdatere backenden i henhold til ændringer! Jeg har kun brugt det i få tilfælde, men det smarte er jo (hvis man lige laver det rigtigt) at den procedure, som checker om backenden skal ændres, bliver slettet når den er blevet udført. Derved skal den ikke checke det hver gang systemet starter op (med mindre at man ønsker at den skal det, selvfølgelig) og proceduren ligger ikke og \'fylder\' i frontenden.

/Thomas

ang. dit P.S., Horus, så er du naturligvis ikke nr 127.300.213,46 da man ikke regner med decimaler.
Men 127.300.213 er tæt på det rigtige ;o))

Jeg husker ellers at du selv lå nr 8-9-stykker på et tidspunkt....Men så kom Terry og fejede alle af banen, haha :o)