Borland database anno 2011

[hell4you]

Als netwerkbeheerder bij MKB bedrijven kom ik heel wat gekke situaties tegen, maar onderstaand verhaal slaat toch wel alles.

Een van mijn klanten heeft onlangs een alles-in-een administratief, calculatie en documentbeheer pakket gekocht. Dit pakket voorziet het bedrijf van de nodige structuur en controle. In het pakket staan vertrouwelijke gegevens, waaronder financiële transacties, projecten, klant relaties, offertes en facturen.

De interface voldoet perfect aan de wensen van de klant, maar de hele onderliggende technische laag is oudbollig en 10 jaar geleden al uitgefaseerd. Zo draaien alle clients een eigen instantie van de borland database engine en staan alle dbase bestanden op een network share. Dit betekent dat de desbetreffende share lees- en schrijfrechten voor alle gebruikers nodig heeft. Zoiets is natuurlijk totaal ongewenst, omdat dit een kwaadwillende de mogelijkheid geeft dingen naar een usb stick te kopiëren of de bestanden direct naar wens aan te passen en daarmee eventueel zelfs de structuur corrupt te maken.

Maar het wordt nog erger. Er staat een configuratiebestand in de root van de windows schijf (lokaal dus!), waarmee door deze aan te passen of te verwijderen gemakkelijk beheerdersrechten verkregen kan worden.

De fabrikant van het pakket is nonchalant, beargumenteert dat de users lokaal geen administrator mogen zijn en wil het geheel niet porten naar SQL of in ieder geval naar een centrale database. Het netwerk krijgt de schuld van de corrupte tabellen en de performance problemen. Het gebruik van de oude technieken wordt afgedaan met de mededeling dat het bewezen technologie is, onder het motto: "Elvis is al lang dood, maar daar luistert men ook nog steeds naar". Nou, dat valt van Windows 95 toch niet meer te zeggen.

Het probleem is dat de klant niet bepaald technisch onderlegd is en daarom is het moeilijk duidelijk te maken dat de problemen voortkomen uit de software en niet uit het netwerk. Wat zijn jullie ervaringen met dit soort situaties en hoe overtuig ik mijn klant dat dit absoluut niet meer van deze tijd is?

[Brahiewahiewa]

Tja, je zou kunnen proberen om je eigen salaris/vergoeding te vertienvoudigen, maar je weet maar nooit hoe zoiets valt.

Als je klant niet voor technische redden vatbaar is, ben jij misschien niet de juiste persoon om 'm te overtuigen; je zou de hulp in kunnen roepen van een vertegenwoordiger/consultant van een fatsoenlijk ERP-pakket.

Derde optie is om de klant te ditchen: als-ie zo weinig aandacht heeft voor automatisering, gaat-ie waarschijnlijk binnenkort wel failliet (samen met de maker van dat administratiepakket)

[DeTeraarist]

Het ditchen van de klant vind ik wat ver gaan, ik zou persoonlijk een rijtje randvoorwaarden aan de klant gaan stellen. Bijvoorbeeld dat het prima is dat ze dat pakket gebruiken, maar dat jij daar geen ondersteuning voor verleend. Als zowel de klant als de uitgever van dat pakket niet voor reden vatbaar zijn, moet je daar zo snel mogelijk je handen aftrekken. Je wilt niet dat de klant jouw straks aanspreekt over de tekortkomingen van een pakket waar jij al voor gewaarschuwd hebt.

[Klippy]

Ben het niet helemaal met je eens, wij ontwikkelen zelf ook nog een pakket met DBF bestanden en losse indexen, pakket moet ook nog een aantal jaar mee gaan en er zijn tal van pakketten die niet SQL-based zijn.
Onze eigen database is Foxpro gebaseerd en dat is ook niet echt nieuw. Voordeel van deze opzet is wel dat je geen SQL server nodig hebt, share aanmaken, beetje configureren en het loopt allemaal. Dat was bij ons een bewuste keuze, zelfs 4 jaar geleden bij een nieuw pakket nog.

De beveiligingsargumenten die je aandraagt vind ik ook niet echt relevant, met SQL is kopieren immers ook niet echt veel lastiger en bijna elk pakket heeft wel een mogelijkheid om de gegevens gewoon te exporteren dus dan is een beveiligde share ook niet echt en hindernis. Los daarvan, als iemand binnen je eigen bedrijf er met de gegevens vandoor wil lukt hem dat op en andere manier ook wel, die mensen werken immers de hele dag met die klantgegevens.

Dan het volgende

Het netwerk krijgt de schuld van de corrupte tabellen en de performance problemen.

Dat zou heel goed kunnen, voor een opzet als deze is je netwerk natuurlijk het primaire overdrachtsmedium. Alle data wordt opgehaald en weggeschreven over je netwerk en je bent afhankelijk van lockingsmechanismen, netwerkprotocollen en beveiligingsinstellingen.
Wij hebben ook regelmatig corrupte tabellen of performance issues bij nieuwe klanten en soms ook netwerkbeheerders die volhouden dat het netwerk niet het probleem is, maar met een beetje voorlichting en configuratie komt het altijd wel goed.
Er zijn namelijk een aantal dingen waarop je moet letten bij deze configuraties, maar dat moet je softwareleverancier je ook kunnen vertellen, dus ik zou voorstellen om daar nog even contact mee op te nemen.
Wij nemen zelf meestal op afstand de server en eventueel de clients over en configureren de boel. Een goede leverancier moet ook goede support kunnen leveren.

De meeste problemen ontstaan overigens door verkeerde softwareconfiguraties, het komt zelden voor dat het netwerk fysiek niet in orde is (al komen we ook wel eens een rotte switch tegen).
Microsoft zelf heeft door de jaren heen ook het een en ander aangepast in zijn SMB protocollen. Met als gevolg dat voor applicaties die afhankelijk zijn van actuele gegevens (zoals DB bestanden) de caching van MS in de weg zit. Vooral bij SMB2 (vanaf Vista en 2003 server) zijn deze problemen aanwezig, maar daar zijn ook hotfixes voor.
Let er verder op dat je geen SMB en SMB2 door elkaar gebruikt.
Meer info over de caching:
Gegevensbeschadiging bij het uitvoeren van meerdere gebruikers lezen en schrijven bewerkingen op een gedeeld bestand in de omgeving SMB2
SMB2 Client Redirector Caches Explained
Meer info over de opportunistic locking (maar dat moet je aan de leverancier vragen of dit van toepassing is):
Improving Performance of MS-DOS Database Applications

Tenslotte zijn er ook een aantal virusscanner die een hoop problemen veroorzaken doordat ze bestanden in gebruik houden. Dit kan leiden tot corruptie of performance problemen. stel die daarom altijd zo in dat ze de map waar de database bestanden staan niet scannen. Vooral Norton en McAfee home edities zijn daar een ramp in. De rest is redelijk goed te configureren.

Samengevat: er komt misschien een klein beetje werk bij kijken, maar ik denk dat je er samen met de leverancier wel uit moet komen. De instelling dat het zeker aan de software ligt is wat kort door de bocht, er zullen zeker meer klanten draaien op dezelfde software. Daarnaast is "even omschrijven" naar SQL natuurlijk geen mogelijkheid, dat zal een compleet niet pakket moeten worden. Een flat-file database is misschien al oud, maar ik zou het nog zeker niet afschrijven.
Dus misschien kan je er met een positievere instelling wel uit komen met de leverancier. Al ben ik het met je eens dat de leverancier zelf ook verantwoordelijk is en wel mee mag denken.

[Brahiewahiewa]

Lees je eigen post nou nog eens door. Je noemt als voordeel dat je geen SQL server hoeft gebruiken en daarna heb je 40 regels text nodig om de problemen op te noemen die je daarmee introduceert. Problemen die allemaal als sneeuw voor de zon verdwijnen als je wel een SQL server gebruikt.

[Klippy]

Het topic gaat toch niet over het voordeel van SQL in het algemeen (ik werk ook liever met SQL).
Het gaat er om dat er nog een hoop software is die er niet mee werkt. Ook een groot pakket als Accountview (om maar een voorbeeld te noemen) is ook FoxPro based.
Dan zeg je toch als systeembeheerder ook niet tegen je klant, die net flink heeft geïnvesteerd, "zeg maar dat ze het omschrijven naar SQL".

Daarnaast is alles wat ik net beschrijf een kwestie van een goede setup maken en dan hoogstens, in extreme gevallen, nog even handmatig wat configureren in 10 minuten tijd.
Het inrichten van een goede SQL server duurt langer.

Ik geef alleen aan dat met goede configuratie, losse DB bestanden nog niet afgeschreven zijn.
Als systeembeheerder moet je zorgen dat de software blijft draaien en niet meteen stellen dat het niet lukt.

Het kan natuurlijk ook zo zijn dat de aangeschafte software gewoon ruk is, maar dat kan ik niet beoordelen van hier natuurlijk.

[hell4you]

Brahiewahiewa schreef op zaterdag 05 november 2011 @ 17:58:
Als je klant niet voor technische redden vatbaar is, ben jij misschien niet de juiste persoon om 'm te overtuigen; je zou de hulp in kunnen roepen van een vertegenwoordiger/consultant van een fatsoenlijk ERP-pakket.

Ja, hier heb ik al over nagedacht, maar ik kan natuurlijk niet zomaar zelf iemand aanwijzen die dan zogenaamd onafhankelijk beoordeelt of het pakket wel of niet voldoet.

DeTeraarist schreef op zaterdag 05 november 2011 @ 18:15:
Als zowel de klant als de uitgever van dat pakket niet voor reden vatbaar zijn, moet je daar zo snel mogelijk je handen aftrekken. Je wilt niet dat de klant jouw straks aanspreekt over de tekortkomingen van een pakket waar jij al voor gewaarschuwd hebt.

Je moet het zo zien. Het bedrijf heeft iemand aangesteld die verantwoordelijk wordt gehouden als het pakket niet naar behoren werkt. Nu blijken er regelmatig problemen te zijn en er wordt een vergadering ingepland waarin de problemen op tafel worden gelegd. De leverancier van de software beargumenteert dat de configuratie van het netwerk niet past bij het pakket. Ze willen dat het gehele pakket onder terminal server komt te draaien zodat de database lokaal staat, maar dit is een enorme overbodige investering omdat er dan opnieuw licenties voor allerlei Microsoft producten moet worden aangekocht. Iedereen heeft nu alles op een eigen werkstation heeft draaien. Daarnaast werkt het bedrijf met zware pakketten zoals bijv. AutoCAD en dat gaat natuurlijk niet werken onder terminal server. De verantwoordelijke binnen het bedrijf wil alleen dat het pakket functioneert en ziet alle kritiek op het pakket als een obstakel. Daarbij geeft de leverancier aan dat de software bij 10-tallen andere klanten prima functioneert en dat de problemen zich alleen hier voordoen.

Klippy schreef op zaterdag 05 november 2011 @ 18:48:
Ben het niet helemaal met je eens, wij ontwikkelen zelf ook nog een pakket met DBF bestanden en losse indexen, pakket moet ook nog een aantal jaar mee gaan en er zijn tal van pakketten die niet SQL-based zijn.
Onze eigen database is Foxpro gebaseerd en dat is ook niet echt nieuw. Voordeel van deze opzet is wel dat je geen SQL server nodig hebt, share aanmaken, beetje configureren en het loopt allemaal. Dat was bij ons een bewuste keuze, zelfs 4 jaar geleden bij een nieuw pakket nog.

Het probleem met deze opzet is dat nagenoeg heel het bedrijf met dit pakket werkt en dat sommige afdelingen helemaal niets met bijv. de financiële administratie te maken hebben. De beveiliging is zo lek als een zeef, want men kan nagenoeg zonder moeite inloggen als beheerder en de gehele databasestructuur kopiëren naar een USB-stick en thuis opstarten is geen kunst aan.

Klippy schreef op zaterdag 05 november 2011 @ 18:48:
De beveiligingsargumenten die je aandraagt vind ik ook niet echt relevant, met SQL is kopieren immers ook niet echt veel lastiger en bijna elk pakket heeft wel een mogelijkheid om de gegevens gewoon te exporteren dus dan is een beveiligde share ook niet echt en hindernis. Los daarvan, als iemand binnen je eigen bedrijf er met de gegevens vandoor wil lukt hem dat op en andere manier ook wel, die mensen werken immers de hele dag met die klantgegevens.

Het gaat er niet direct om dat ze de gegevens waar ze toegang hebben kunnen kopiëren, maar juist de gegevens waar ze totaal niets mee te maken hebben. Nu is dat niet moeilijker dan een programma te downloaden en het database bestand te openen.

Klippy schreef op zaterdag 05 november 2011 @ 18:48:
Tenslotte zijn er ook een aantal virusscanner die een hoop problemen veroorzaken doordat ze bestanden in gebruik houden. Dit kan leiden tot corruptie of performance problemen. stel die daarom altijd zo in dat ze de map waar de database bestanden staan niet scannen. Vooral Norton en McAfee home edities zijn daar een ramp in. De rest is redelijk goed te configureren.

Bij dit bedrijf draait Kaspersky for workstations. Er is een poging gedaan met de virusscanner uitgeschakeld, maar dezelfde problemen deden zich voor.

[Brahiewahiewa]

De leverancier van de software beargumenteert dat de configuratie van het netwerk niet past bij het pakket. Ze willen dat het gehele pakket onder terminal server komt te draaien zodat de database lokaal staat, maar dit is een enorme overbodige investering omdat er dan opnieuw licenties voor allerlei Microsoft producten moet worden aangekocht.

Dus de leverancier geeft zelf ook al aan dat de software niet geschikt is om over het network te draaien?
Daarmee prijst-ie zichzelf regelrecht het graf in*). Want feitelijk moet je dan de kosten voor de terminalserver en de bijbehorende licenties bij de prijs van het product optellen. Is dat niet een argument om de directie te overtuigen?

Overigens betekent het feit dat je een applicatie via terminalserver draait niet dat je alle applicaties via terminal server hoeft te draaien. MS heeft daar hele mooie oplossingen voor. Maar per saldo heb je dan zowel de nadelen van SBC als van fat-clients.

*) (c) Wim Sonneveld

[Gomez12]

Brahiewahiewa schreef op maandag 07 november 2011 @ 02:38:
[...]
Dus de leverancier geeft zelf ook al aan dat de software niet geschikt is om over het network te draaien?
Daarmee prijst-ie zichzelf regelrecht het graf in*). Want feitelijk moet je dan de kosten voor de terminalserver en de bijbehorende licenties bij de prijs van het product optellen. Is dat niet een argument om de directie te overtuigen?

Zo ongewoon is het helemaal niet hoor om iets voornamelijk via TS te kunnen draaien.

Ik ken nog zat SQL-pakketten die ook enkel onder TS geadviseerd worden te draaien. LAN-latency's werken nu eenmaal veelal anders als je vestigingen etc hebt.

Daarom kan ik me ook wel enigszins in de post van Klippy vinden, enkel zou ik niet de problemen gaan bestrijden via omwegen, maar simpelweg TS aanraden voor goede performance.
Ik zou enkel ver weg blijven bij leveranciers die SMB-instellingen willen wijzigen / virusscanners uit willen zetten etc. Je fixend dan links iets en rechts valt er iets anders om omdat dat beruste op die instellingen.
Foutieve instellingen (voor dat pakket) mogen performance verlies opleveren, maar nooit bestandscorruptie.

Bestandscorruptie is wmb simpelweg onbespreekbaar.

[Klippy]

Wij leveren bij de grotere klanten ook liever TS omgevingen inderdaad (> 5 a 6 werkstations).
Maar dan kost wel wat meer ja. Is qua performance ook zeker de beste oplossing, alleen vind ik niet dat je daartoe verplicht moet worden.

Lastige situatie dus. In dat geval moet je de klant goed betrekken bij het overleg met de leverancier. Zodat die weet dat het niet aan jou ligt en hem laten kiezen om evt voor TS oplossing te gaan als hij dat het geld waard vindt.

Gomez12 schreef op maandag 07 november 2011 @ 03:15:
[...]
Ik zou enkel ver weg blijven bij leveranciers die SMB-instellingen willen wijzigen / virusscanners uit willen zetten etc. Je fixend dan links iets en rechts valt er iets anders om omdat dat beruste op die instellingen.

Valt wel mee hoor, ik had het hier over 2 en soms 3 registry keys en een uitsluiting in de virusscanner voor de data map (wat niet eens perse nodig is bij een goede scanner).
Dat is één optimalisatie waar je verder geen last van hebt en die MS ook adviseert in te stellen in dit soort situaties.
Het ging me er meer om het punt te maken dat je vaak met één of twee kleine tweaks al heel ver kan komen

[ Voor 44% gewijzigd door Klippy op 07-11-2011 09:37 ]