Regler for 'direkte' C5 SQL adgang?

At alle Bogføringsregler bliver overholdt.

Hvad er det for en type data du vil sætte ind ?

Problemet er, at C5 er konstrueret sådan at data går gennem skærmbillederne. Der ligger en masse kode på de enkelte felter, på blokkene, på forms og de kalder typisk endnu mere kode i kørsler og macroer.
Vil du opdatere varepriser, så gælder et sæt regler, vil du opdatere debitoroplysninger, så gælder et andet sæt regler. Vil du oprette ordrer eller på anden vis lave ting, der er lidt mere komplicerede end ren datamanipulation, så er det naturligvis muligt, men du skal have fat i en stor del af den kode, der ligger i C5, i dine kørsler. Det største problem er faktisk konsistente data, fordi der er en række helt specielle krav til data i et bogføringssystem. Det er f.eks ret upraktisk med et-benede posteringer, og der kommer i hvert fald sjove lyde fra din regnskabschef, hvis han finder sådan en.

Spørgsmålet var måske lige lovligt generelt, det jeg prøver er at "replikere" hvad den gamle C5 ODBC driver gjorde, altså sørge for reglerne bliver overholdt.

Det jeg specifikt søger af information er -

1. Hvad gør man lige ved SEQNO/DATSET? Kan man 'bare' lægge 1 til?
2. Hvorfor er det lige C5 ikke gider <NULL> i SQL, men partout skal bruge en tom firkant (0x02h svjv.), betyder det at man selv skal sætte 0x02 ind i stedet for <NULL>?
3. Generelle huske regler af jer der rent faktisk gør brug af denne mulighed.
4. Hvad med alt det jeg ikke har opdaget indtil videre (når vi ser bort fra samtlige regler i C5 applikationen)?

Pt. har jeg ikke i tankerne at skyde data direkte ind i Finans og andre sjove kartoteker, så ovenstående går udelukkende på 513+ kartoteker.

1: Nej, du skal bruge den stored-procedure, som C5 installerer. sp_xalseqno
2: Du må ikke bruge NULL værdier. NULL kan ikke søges på vha. "=" eller sorteres. Grunden til at C5 bruger 0x02 stammer tilbage fra SQL Server 6.0/6.5, som brugte NULL til at registrere en blank streng. En blank streng er ikke det samme som NULL. Derfor bruger C5 0x02, da denne værdi er næsten ligeså lav som <blank> og derfor sorteres korrekt.
3: Datoer skal indsættes som klokken 00:00:00 den dag. Hvis feltet er højrejusteret så skal du selv indsætte mellemrum foran.

Kommer man ud i gris, hvis man bruger triggers på tabellerne?

Ja, fordi C5 godt kan finde på at omdøbe, flytte indholdet og derefter slette tabellen. Derved forsvinder triggerne også. C5 ved heller ikke hvordan den skal håndtere en fejl sendt fra en trigger...

Noget andet er at jeg ikke helt ved hvordan de evt. triggers skulle styres, således den ikke kommer i karambolage med C5 selv, men det kan vel kodes til.

Nå men pkt. 4 tænker jeg på hvad der er 'forbudt' at skrive af XAL kode i C5, altså, hvad skal man undgå, så den allerede underholdende hastighed ikke bliver værre?

Findes der en connector eller lign. der tager sig af det du nævner med højrestilling osv osv.?

Hvis hastigheden er 'underholdende' er det pga. fejlopsætning eller underdimensionering af hardware.

Man skal sørge for at foretage så få opslag i databasen som muligt, men det gælder jo på alle systemer.

Der findes umiddelbart ikke nogen connector... Jeg har idéen til en, men det er lige med at få tiden til at lave den.

Jeg havde jo helt glemt at give dig en bunke point.

Mht. til "connectoren", du må endelig skrive på min email såfremt du finder en fancy løsning.

I øvrigt, jeg fandt ud af at den "underholdende" hastighed primært kom fra LagPris->Update TRG. Fjerner jeg den, flyver den afsted.

Men der er stadigvæk /meget/ langt op til "ren" SQL (læs: alt det der ikke har med cursors at gøre :).