[ALG] Database update uitvoeren

[pjvandesande]

Wij hebben een software pakket die bij een groot aantal bedrijven draait. Zoals elk software pakket brengen wij ook voor ons pakket updates uit. Het pakket word automatisch geupdate met een bepaalde interval.
Het updaten van de exe's en dll's geeft helemaal geen problemen, hier hebben wij onze eigen update manager voor geschreven maar zou ook prima kunnen met InstallShield of iets dergelijks.

Nu zitten er ook wel is wijzigingen in de database. Bijvoorbeeld als er een nieuwe future is toegevoegd moet er een tabel gecreerd worden in de bestaande database. Maar er moeten soms ook velden gewijzigd worden, het veld naam moet bijvoorbeeld van size 50 naar size 125 omdat er langeren namen ingevoerd kunnen worden of er moet een veld geindexeerd worden bij de update.
Zo kun je nog een hoop situaties bedenken waarbij de database structuur gewijzigd moet worden.

Zelf had ik een universeel datamodel bedacht. Dus dat de update a.d.h.v. een database model in XML de huidige database structuur bekijkt en deze aanpast. Omdat er klanten zijn die het pakket i.s.m. Access draaien tot klanten die het draaien met MSSQL. Daarom is een universeel database model natuurlijk idiaal, a.d.h.v. dat model kan ik dat de dabase gaan aanpassen.

Nu is alleen het probleem dat je bijvoorbeeld in Access niet de gehele database structuur kan opvragen, dus dat je ook niet precies weet wat er nou veranderd moet worden.

Hoe gaan jullie hier mee om en zien jullie hier oplossingen voor?

[FendtVario]

Voor ons programma (wat overigens geen verschillende dbms-sen gebruikt) draait heb ik ook een updater gemaakt. De gehele structuur wordt in XML aangelevert en via een een programma wordt de database structuur vergeleken met de XML. Gelukkig kan de structuur van de database omgevraagd worden ook gewoon de SQL dus dat is relatief simpel. De wijzigingen worden eerst getelt, daarna wordt om een beheerderswachtwoord gevraagt. Als dit is ingegeven wordt de wijzigingen uitgevoerd.

Overigens kan het update programma niet alles wijzigen in de database. Zo kunnen er geen velden of tabellen verwijderd worden. Wel kunnen velden van lengte veranderd worden, velden bijgemaakt of sleutels worden bijgemaakt.

[pjvandesande]

Het grootste probleem is eigelijk Access, ik kan op geen mogelijkheid de database structuur van Access opvragen. Een hoop info kan ik wel krijgen, maar niet alles.

Nu is het de vraag om dan misschien toch Access te gaan schrappen, maar er zijn gewoon klanten die om hun policy geen database server geinstalleerd willen hebben. Dus dat is dan ook weer een probleem. Misschien zouden we dan moeten kijken naar een alternatief voor Access.

[MrBucket]

questa schreef op woensdag 09 maart 2005 @ 15:22:
Het grootste probleem is eigelijk Access, ik kan op geen mogelijkheid de database structuur van Access opvragen. Een hoop info kan ik wel krijgen, maar niet alles.

Of je zou moeten overwegen om hetgene wat je niet rechtstreeks uit de database kan afleiden in een apart bestand op te slaan, zodat je die informatie toch tot je beschikking hebt. Bij het updaten van de database door je script zou het tegelijkertijd deze file aan moeten passen, zodat deze de nieuwe database-toestand reflecteert.

Het risico hierbij is natuurlijk dat er geen garantie is dat de informatie in het extra bestand overeenkomt met de structuur van de database. Er hoeft maar 1 iemand "even snel" een aanpassing aan de structuur te willen maken (zonder het extra bestand mee aan te passen), en je hebt de poppen aan het dansen...

[FendtVario]

Ik ken Access niet meer dan het maken van een paar tabellen en het maken van relaties tussen die maar het lijkt met sterk als je wel iets kan maken maar daarna niet meer kan opvragen wat je gemaakt hebt. Als ik in Delphi een paar ADO componenten op mijn formulier sleep zijn die ook in staat om de tabel structuur op te vragen. Waarom zou jij dat niet kunnen?

[The Eagle]

Breng een soort "Professional" versie uit, die wel met diverse DBMS'sen om kan gaan. Daarin zet je dan alle updates die op DBMS'sen betrekking hebben.
Overigens is Access in mijn ogen geen DBMS, maar da's persoonlijk

[pjvandesande]

MrBucket schreef op woensdag 09 maart 2005 @ 15:27:
[...]

Of je zou moeten overwegen om hetgene wat je niet rechtstreeks uit de database kan afleiden in een apart bestand op te slaan, zodat je die informatie toch tot je beschikking hebt. Bij het updaten van de database door je script zou het tegelijkertijd deze file aan moeten passen, zodat deze de nieuwe database-toestand reflecteert.

Het risico hierbij is natuurlijk dat er geen garantie is dat de informatie in het extra bestand overeenkomt met de structuur van de database. Er hoeft maar 1 iemand "even snel" een aanpassing aan de structuur te willen maken (zonder het extra bestand mee aan te passen), en je hebt de poppen aan het dansen...

Hiermee ga ik aan de slag. Dus dan krijg je een Access database met daarnaast een structuur bestand en aan der hand van het structuur bestand ga ik wijzigingen doorvoeren. Dit vind ik een geniale oplossing, misschien niet helemaal waterdicht maar als de klant de DB zelf wilt aanpassen en alles verneuken moet hij dat toch echt zelf weten.

FendtVario schreef op woensdag 09 maart 2005 @ 15:33:
Ik ken Access niet meer dan het maken van een paar tabellen en het maken van relaties tussen die maar het lijkt met sterk als je wel iets kan maken maar daarna niet meer kan opvragen wat je gemaakt hebt. Als ik in Delphi een paar ADO componenten op mijn formulier sleep zijn die ook in staat om de tabel structuur op te vragen. Waarom zou jij dat niet kunnen?

Je kunt een hoop opvragen maar niet alles. Als ik een schema opvraag (IDataReader.GetSchema()) geeft dit een hoop terug. Alleen dingen als bijvoorbeeld index kun je weet niet opvragen.

The_Eagle schreef op woensdag 09 maart 2005 @ 15:43:
Breng een soort "Professional" versie uit, die wel met diverse DBMS'sen om kan gaan. Daarin zet je dan alle updates die op DBMS'sen betrekking hebben.
Overigens is Access in mijn ogen geen DBMS, maar da's persoonlijk

Dat hebben we al, hij werkt al met diverse DBMS's waar Access dus ook onder valt. Het gaat er nu alleen om hoe je dit het beste kunt update.

[Verwijderd]

questa schreef op woensdag 09 maart 2005 @ 15:22:
Het grootste probleem is eigelijk Access, ik kan op geen mogelijkheid de database structuur van Access opvragen. Een hoop info kan ik wel krijgen, maar niet alles.

Met TableDefs en QueryDefs kun je anders alle informatie over de opbouw van een tabel/query opvragen voor zover ik weet. Welke informatie kun je niet krijgen ?

[pjvandesande]

Verwijderd schreef op woensdag 09 maart 2005 @ 15:59:
[...]

Met TableDefs en QueryDefs kun je anders alle informatie over de opbouw van een tabel/query opvragen voor zover ik weet. Welke informatie kun je niet krijgen ?

De twee waar is zo tegen aangelopen ben is de Indexed propertie, dus of het veld geindexeerd is of niet en of er duplicaten in mogen zitten, de IsUnique geeft namelijk altijd false terug.

TableDefs is trouwens nog van DAO, in ADO kennen we dit niet meer. Maar opzich is dat het probleem niet, maar denk niet dat TableDefs mij meer kan vertellen dan de schema's van ADO.

[ Voor 17% gewijzigd door pjvandesande op 09-03-2005 16:10 ]

[Orphix]

Bekijk eens Sql Compare.
Ik heb ook een tijd met dit probleem rond gelopen. Maar bij m'n eigen oplossingen liep ik toch al snel vast op bv dependencies van de verschillende db objecten. Dit programma houdt daar wel rekening mee en het bevalt me erg goed. Het is ook gemakkelijk aan te roepen vanuit buildscripts of je eigen programmatuur dus ook in je installatieprogramma.

[LuCarD]

questa schreef op woensdag 09 maart 2005 @ 16:09:
[...]


De twee waar is zo tegen aangelopen ben is de Indexed propertie, dus of het veld geindexeerd is of niet en of er duplicaten in mogen zitten, de IsUnique geeft namelijk altijd false terug.

TableDefs is trouwens nog van DAO, in ADO kennen we dit niet meer. Maar opzich is dat het probleem niet, maar denk niet dat TableDefs mij meer kan vertellen dan de schema's van ADO.

Kan je stomweg de index droppen en opnieuw aanmaken? Duurt de conversie wel wat langer maar dan hadden ze ook maae een echte DB moeten gaan gebruiken

En met unique, is het nog simpeler. Je weet toch in welke velden unique moeten zijn in de update. Deze maak je gewoon aan, krijg je een error dan ga je testen op dubbele waarden. En zijn er dubbele waarden dan geef je dat terug aan de gebruiker. En doe je een rollback op de hele conversie.

Oke dit is wel een beetje struisvogel politiek maar het werkt wel.

[farlane]

Kun je met die ADOX componenten niet iets meer doen?

[Verwijderd]

questa schreef op woensdag 09 maart 2005 @ 16:09:
[...]


De twee waar is zo tegen aangelopen ben is de Indexed propertie, dus of het veld geindexeerd is of niet en of er duplicaten in mogen zitten, de IsUnique geeft namelijk altijd false terug.

TableDefs is trouwens nog van DAO, in ADO kennen we dit niet meer. Maar opzich is dat het probleem niet, maar denk niet dat TableDefs mij meer kan vertellen dan de schema's van ADO.

1 : Ik weet dat tabledefs etc. nog van DAO zijn, maar uit ervaring weet ik dat er beter mee te werken is dan met ADOX.

2 : een tabledef heeft een "Indexes"-collection, waarmee je de afzonderlijke indexen op die tabel uit kunt kunt lezen, kunt zien of het een unique index is, en welke velden er in zitten.

[pjvandesande]

Orphix schreef op woensdag 09 maart 2005 @ 17:24:
Bekijk eens Sql Compare.
Ik heb ook een tijd met dit probleem rond gelopen. Maar bij m'n eigen oplossingen liep ik toch al snel vast op bv dependencies van de verschillende db objecten. Dit programma houdt daar wel rekening mee en het bevalt me erg goed. Het is ook gemakkelijk aan te roepen vanuit buildscripts of je eigen programmatuur dus ook in je installatieprogramma.

Deze werkt alleen met SQL server, of ik moet weer is niet goed gekeken hebben. In SQL server kun je eigelijk alle informatie wel verkrijgen, alleen ik zit met het probleem dat er ook Access gebruikt word.

farlane schreef op woensdag 09 maart 2005 @ 18:08:
Kun je met die ADOX componenten niet iets meer doen?

Zou ik even moeten uit docteren. Thanks voor de tip!

Verwijderd schreef op woensdag 09 maart 2005 @ 18:12:
[...]

1 : Ik weet dat tabledefs etc. nog van DAO zijn, maar uit ervaring weet ik dat er beter mee te werken is dan met ADOX.

2 : een tabledef heeft een "Indexes"-collection, waarmee je de afzonderlijke indexen op die tabel uit kunt kunt lezen, kunt zien of het een unique index is, en welke velden er in zitten.

Ik zie inderdaad dat DAO iets meer terug geeft. Maar opzicht vind ik de oplossing die MrBucket eigelijk wel mooi.

[FendtVario]

questa schreef op donderdag 10 maart 2005 @ 08:47:Ik zie inderdaad dat DAO iets meer terug geeft. Maar opzicht vind ik de oplossing die MrBucket eigelijk wel mooi.

Wil je echt het risico lopen dat definitiebestand en database niet synchroon lopen? Als je direct uit de database leest heb je altijd de relevante gegevens. Ook bespaar je jezelf het werk van het maken van zo'n definitiebestand.

[_Thanatos_]

Als het goed is, kun je op een nette OO manier met ADOX tabellendefinities en alles erop en eraan opvragen en manipuleren. Zie ADOX API Reference.

[Verwijderd]

_Thanatos_ schreef op donderdag 10 maart 2005 @ 11:36:
Als het goed is, kun je op een nette OO manier met ADOX tabellendefinities en alles erop en eraan opvragen en manipuleren. Zie ADOX API Reference.

Zoals ik al eerder zei, raad ik aan om ADOX niet te gebruiken. Wanneer je bijvoorbeeld via ADOX een tabel toevoegt aan Access, is deze vanuit Access niet te zien, terwijl hij WEL aanwezig is.

[_Thanatos_]

Hm, dat zei je inderdaad

Maar dat is toch niet erg? Ik neem aan dat het programma Access niet gebruikt wordt, maar alleen de achterliggende Jet database engine?

[ Voor 11% gewijzigd door _Thanatos_ op 10-03-2005 11:46 ]

[farlane]

Verwijderd schreef op donderdag 10 maart 2005 @ 11:41:
[...]

Zoals ik al eerder zei, raad ik aan om ADOX niet te gebruiken. Wanneer je bijvoorbeeld via ADOX een tabel toevoegt aan Access, is deze vanuit Access niet te zien, terwijl hij WEL aanwezig is.

Wat is daar de reden van? Ik heb het enkele keren gebruikt maar nog niet iets van die strekking gezien.

[Verwijderd]

farlane schreef op donderdag 10 maart 2005 @ 12:38:
[...]


Wat is daar de reden van? Ik heb het enkele keren gebruikt maar nog niet iets van die strekking gezien.

De reden ? Ik zou niet weten waarom het gebeurt, maar een collega en ikzelf hebben het meerdere malen meegemaakt. misschien dat het ook verschilt per versie van ADO.

[Oktopus]

In de software die ik geschreven heb hou ik een versie nummer bij van de database. Deze wordt uit de database gelezen en vergeleken met een constante in het programma. Is de versie van de database lager dan moet je de database gaan aanpassen met de wijzigingen op je tabellen. Is de versie hoger dan moet de software geupdate worden. Op deze manier weet je zeker dat er geen vervuiling of ontbrekende gegevens onstaan.