🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: dk.edb
Article #151

Re: Forsvundne fakturaer: XAL native database

#151
From: Ulrik Lunddahl
Date: Sat, 09 May 1998 00:00
89 lines
5129 bytes
Carsten Overgaard wrote in message <01bd78e7$4308ca70$0a14a0c0@FG_P01>...

>Programmet k�rer p� NT 4.0 med NT 4.0 WS (DK). Der er ca. 16 brugere,
>hvoraf 7-8 personer konstant opholder sig i ordrekartoteket i samtlige
>timer. Der dannes ca. 450 ordrer om ugen og der faktureres tilsvarende.

Et ganske lille load systemets st�relse taget i betragtning.

>Vi har oplevet et mystisk f�nomen, som vi ikke kan f� forklaring p�, da vi
>er de f�rste i verden med dette problem.

Jeg kan garantere jer at i ikke er de f�rste der har oplavet noget mystisk
p� en Concorde installation, hverken XAL, eller C4 er s�rligt gode til at
h�ndtere fejl i de lagrede data.

>Vi st�r med 14 fakturaer i h�nden, som ikke er registeret i databasen, men
>er udskrevet derfra. De forefindes hverken i lagerposteringer,
>debitorposteringer, som ordrelinier og i finanskartoteket.

Jeps, kunne v�re fordi der mangler noget i de tabeller som fakturaen
relaterer til, f.eks. en fejl p� debitorens stamkort, eller en fejl p� et af
de lagerkort hvor varen indg�r i fakturaen.

>Vor forhandler, som i�vrigt afviser at have set f�nomenet f�r, har kommet
>med en teori, at XAL's cache p� arbejdsstationen skulle v�re g�et tabt og
>at vi derfor skulle �ndre p� parametren (-P) fra 10 til 5.

Hmmm, lyder ikke ret sansynligt, er alle 14 fakturaer laver fra den samme
arbejdsplads, eller indeholder de alle en speciel vare, eller er de alle p�
den samme debitor.

>Er der andre, som har oplevet tilsvarende f�nomen?

Ikke med XAL, men med C4 har vi oplevet MANGE besynderlige ting, vi er
registrerede som beta testere p� C4 hos damgaard, hvilket giver os ret til
at komme med fejlraporter som bliver unders�gt, men deres standard er
rimeligt lav systes jeg, i 90% af tilf�ldende kan de ikke genskabe fejlen,
selv om vi kan g�re det p� nyt udstyr med ren instalation i 100% af
tilf�ldende.

F.eks. findes der over 10 m�der at f� den nyeste version af C4 til at g� ned
med Division by Zero, hvilket ikke burde kunne ske overhovedet.

Blandt andet har den et par graverende fejl i ordremudulet, ved at lave
ganske specielle ordrer kan man f� varerne til at forsvinde og komme igen,
helt ud af den bl� luft, fra lageret, jeg kan g�re det p� alle C4
instalationer, men Damgaard n�gter at fejlen findes.

Til slut er der Pop Down funktionen (udokmenteret), helt tilf�ldigt
forsvinder det DOS vindue (under Windows95) som man arbejder i, Hvis man er
rigtig hurtig kan man se at der kommer en runtime error, men Damgaard har
lavet det s�dan at efter en runtime error bliver der sendt en ALT-F4 s�
kunden ikke kan se er er en fejl.

Herefter er ordren/indk�bet sp�ret, og eneste metode er at frigive
systeml�se og s� reindexsere, hvilket godt kan tage en time eller to.

Og nej, det er ikke maskinerne, det er pr�vet p� s� mange forskellige, fra
P2 til 486 og p� flere forskellige operativsystemer.

S� du er ikke den eneste der har oplevet noget m�rkeligt med damgaards
produkter.

Grunden til at disse fejl kommer er at Damgaards systemer ofte er 2 teer,
alts� det er klienten der st�r for opdateringen direkte i dataene i basen,
og der mangler simpelthen et centralt k�rende program der kan sikre at en
hel operation f�rst skrives til basen n�r den kan skrives korrekt.
Ovenst�ende sammen med det faktum at klienterne er meget d�rlige til at
h�ndtere forkerte data i databasen kan give et meget ustabilt system.

Pr�v f.eks. at hente date med en ODBC driver, kan du f.eks. finde en debitor
med ulovlige v�rdier i nogen af felterne, f.eks. v�rdi 12943183748723167 i
betalingsbetingelserne, n�r der kun er tilladt fra 1-100 s� pr�v at se
hvordan klienten h�ndterer dette, hvis den g�r ned, midt i en opdatering af
en faktura, her du sikkert en masse sk�ve 1 bens posteringer, og disse kan
s� v�re kilde til nye fejl.

Et lille program skrevet i access der kontrolerer de data der ligger i basen
kan v�re guld v�rd, Damgaards Reindexering checker nemlig ikke om de date
der findes er valide, ej heller ikke om referencerne er i orden, der eneste
der sker er at du f�r nogen nye index, baseret p� de nuv�rende data, om de
s� er valide eller ej, checkes ikke.

Med Venlig Hilsen

Ulrik Lunddahl.

Skrevet med n�sten 10 fingersystem, ignorer venligst stave/sl� fejl.
Technical Details
Message-ID: <6j1t9s$3cig$1@news-inn.inet.tele.dk>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <01bd78e7$4308ca70$0a14a0c0@FG_P01>

Show Full Headers
Complete Article Headers
X-Google-Language: DANISH,ASCII
X-Google-Thread: fa6f6,d598acd4582e98c6
X-Google-Attributes: gidfa6f6,public
X-Google-Thread: fcdf9,d598acd4582e98c6
X-Google-Attributes: gidfcdf9,public
X-Google-Thread: 10ad1d,d598acd4582e98c6
X-Google-Attributes: gid10ad1d,public
From: "Ulrik Lunddahl" <lunddahl@post1.tele.dk>
Subject: Re: Forsvundne fakturaer: XAL native database
Date: 1998/05/09
Message-ID: <6j1t9s$3cig$1@news-inn.inet.tele.dk>
X-Deja-AN: 351736879
References: <01bd78e7$4308ca70$0a14a0c0@FG_P01>
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Organization: IT-Consult
Newsgroups: dk.edb,dk.edb.database,dk.edb.programmering