21. april 2004 - 11:19Der er
8 kommentarer og 1 løsning
Komplet oversigt over C5 tabelstruktur
Jeg arbejder pt. på et ledelsesinformationssystem (LIS), hvor jeg blandt andet skal bruge data fra C5. Da de 150-170 tabeller ikke ligefrem fremstår som sigende for mig, savner jeg et dokument der beskriver sammenhænge imellem tabellerne. Eventuelt også kolonnerne, og hvilke spidsfindigheder der måtte ligge der. Lidt ala en "Coders first guide to XXX" :)
Skulle det være et "fortroligt/internt dokument", vil det bliver behandlet med største diskretion.
Jeg mener da det er lige til at generelt kunne sige hvad en Tabel bruges til, fx. DebKart er DebitorKartoteket og fx. KreKart er Kreditor kartoteket osv.
Ja, de tabeller er jeg også godt klar over. Problemet er blot, at jeg ikke har nogen erfaring med udvikling i C5. De mange tabeller er givetvist knyttet sammen i koden, og de sammenhænge vil jeg meget gerne kunne trække på, uden at risikere at lave nogle fejl. Endvidere, såfremt der skulle være nogle funktionelle sammenhænge mellem visse columns, kunne det jo være rart at kende disse, uden at skulle "gætte sig frem".
Eksempelvist: hvad knytter debkart sammen med debpost? er det løbenummer, fileid, recid, konto eller noget andet?
Det findes så vidt jeg ved ikke. Hovedsaglig fordi det vil være et kæmpe arbejde at lave, og til hvad formål? Når vi som programmører skal bruge noget, så checker vi bare op hvilke felter, der er relationerne, og skal vi bruge andre, så laver vi dem. Og resten er en del af den viden, vi slæber rundt på.
Der er god grund til at have det - dels fordi det giver mening for "nytilkomne", og dels fordi det ikke er til at se hvilke felter der er relaterede hvordan for folk "udefra" - hvilket gør udvikling af 3. parts produkter mere besværlig.
Nogen må have en form for information, eller liste over hvilke egenskaber der er, og hvad de bruges til - det kan ikke passe, at alle C5 huse er så udokumenterede - hvis det forekom i andre softwarehuse ville der være folk med meget røde ører :)
Vi dokumenterer hvilke ændringer, vi foretager, men jeg har aldrig haft behov for at kende hele strukturen og alle relationer. Når jeg udvikler 3.parts produkter, så sørger jeg for at de relateres til den eksisterende struktur, og ikke omvendt. Det gør opdateringer betydeligt nemmere = billigere for kunden.
Når du siger "egenskaber" så er vi inde i applikationsdelen, og den er ganske fint dokumenteret i manualen.
Native er en ganske almindelig relationsdatabase. Hvis du har behov for noget specifikt, så spørg - så forsøger vi at svare efter bedste evne.
Dokumentation på standardsystemerne og det gamle Damgaard Data må siges at have været to uforenelige størrelser. Hvis der fandtes noget dokumentation var det i hvert fald noget Damgaard Data holdt for sig selv på c5. (Historisk: Damgaard Data fusionerede med Navision, som så blev købt af Microsoft).
De lavede faktisk noget til XAL, men det blev også droppet igen. Så faktisk er det ikke C5-husenes/forhandlernes skyld, at de ikke ligger inde med noget dokumentation, oprindeligt må den tilskrives producenten.
Nuvel, når det så er sagt, kan vi da nævne, at der dog i applikationen er anvendt en kodestandard, som måske kan hjælpe dig lidt på vej.
Alle tabeller, som har et tilhørsforhold til et bestemt modul, er prefixet med en betegnelse som beskriver modulet:
Finans - Fin Lager - Lag Debitor - Deb Kreditor - Kre SalgsOrdre - Ord Indkøbsordre - Ind Projekt - Pro
Alle stamtabeller, som tilhører et bestemt er efter prefixet ydeligere navngivet med en betegnelse som beskriver, om der er stamdata, eller bevægelser/posteringer. Stamdata - Kart Posteringer - Post. Derfor hedder stamtabellerne i modulerne: Finans - FinKart Lager - LagKart Debitor - DebKart Kreditor - KreKart SalgsOrdre - OrdKart Indkøbsordre - IndKart Projekt - ProKart
Og posteringstabellerne til modulerne hedder: Finans - FinPost Lager - LagPost Debitor - DebPost Kreditor - KrePost SalgsOrdre - OrdPost Indkøbsordre - IndPost Projekt - ProPost Posteringer er i c5 terminologi noget som er blevet bogført.
Så er der Kladdetabeller, som er en slags forstadie til posteringer. Når man bogfører en kladde, bliver linierne i kladden til posteringer. Altså er kladdetabellerne noget som ENDNU IKKE er bogført.
Der er også Gruppe-tabeller, som grupperer stamdata-records i grupper. DebGruppe KreGruppe LagGruppe OrdGruppe IndGruppe ProGruppe
Ligeledes kan gruppetabellerne indeholde karakteristika, som
Det er sådan grundsubstansen i det.
Endelig kan jeg da nævne at der i C5, hvis du trykker CTRL+F12 og vælger punktet Kartoteker, er en slags browser, hvor du kan få et overblik over alle tabeller. Med hensyn til relationer, vises simple relationer (felt-til-felt-relationer) øverste i dette skærmbillede med rød skrift på formen Tabel.Feltnavn, når du stiller markøren på et felt i tabellen.
Hvis du vil have en nærmere forklaring på dette, så må du lige poste her igen, så skal jeg skrive en med skærmdumps.
Endelig er relationer egentlig kun synlige ved, at man navngiver felter, som indeholder nøgleværdier som binder tabellerne sammen, med det samme navn på tværs af tabellerne.
Et eks.:
FinPost.Konto (som er en bogført post) relateres til Finkart.Konto (som er kontokortet).
Ellers kan man typisk også udlede relationer hvis man kigger lidt på de enkelte indekses der er defineret på tabellerne.
Pyeh for en smøre. Jeg synes næste jeg fortjener points bare for indsats ;) ;)
det syntes jeg også, jasman. Jeg kan dog nævne, at jeg har haft snakket med Microsoft Business Solutions, og nu har lavet et program, der kan tage en vilkårlig C5 database, og generere et oversigtsbillede over de relationer der er i C5.
Skulle i være interesserede i at få en sådan relationsoversigt, kan i bare sende et struktur dump til mig i en zip fil, og så kan vi jo nok finde ud af noget - jeg har nemlig nogle spørgsmål til logikken i C5, og så kan jeg til gengæld levere en oversigt :)))
til dagligt arbejder jeg nu ikke med C5, men fortrinsvis Axapta. Axapta er født med en SQL-backend imodsætning til C5 og XAL, så her har man nogle lidt bedre muligheder for at danne sig et overblik (der er nemlig et værktøj til det - ikke et superperfekt et, men det er der). Det er også nødvendigt, da antallet er tabeller i forhold til XAL er ca. tredoblet.
Men, hvis jeg skulle få brug for det, så skal jeg nok tænke på dig.
En anden mulighed er at anskaffe et ledelsesinformationssystem med en færdig datamodel. Det vil både spare dig arbejde plus du kan se i systemets datamodel, hvordan tingene hænger sammen i databasen.
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.
Ny bruger
Nybegynder
Opret
Preview
