Virtualiseren software i.c.m. databases

[PP90134]

Beste tweakers,

Momenteel ben ik bezig voor een project om software van verschillende locaties te centraliseren. Achter bepaalde software (van derde partijen) hangt een mdb database met gegevens die zijn gevuld van een formulier uit het softwarepakket. Nou wil ik van deze databases 1 database maken, wat ook prima kan. Echter wil ik wel dat de gegevens per locatie zijn afgeschermd. Helaas kan ik de database en software niet aanpassen, dus een autorisatiecheck in de database bouwen kan niet. Ik heb hier over nagedacht hoe ik dit het best kan oplossen maar helaas nog niet met een passende oplossing gekomen. We gaan overigens waarschijnlijk XenApp gebruiken.
Misschien hebben de mede-tweakers hier een idee?

Groeten

[ Voor 3% gewijzigd door PP90134 op 07-06-2012 12:55 ]

[Freezerator]

Kan je nog een keer proberen dit wat duidelijker uit te leggen wat je nou precies wil?

[Arie-]

Allereerst de vraag waarom is het nodig dat deze databases gecombineerd moeten worden, misschien is dit niet nodig en is de daadwerkelijke oplossing veel eenvoudiger, is de software op de verschillende locaties hetzelfde maar mogen zij elkaars data niet inzien? In dat geval is het misschien makkelijker om de verschillende system los van elkaar te virtualiseren op één server. Of is het doel makkelijker management informatie uit de gecombineerde systemen te kunnen halen.

[PP90134]

Bedankt voor je reactie Arie- en Freezerator, de software is inderdaad hetzelfde. Het gaat puur om te zorgen dat de software en database/databases op 1 locatie zijn. Het hoeft niet persé in 1 database; meerdere databases is ook gewoon goed mogelijk. Het aller belangrijkste is dat de gegevens gescheiden zijn en dat niet locatie X bij de gegevens van locatie Y kunnen.

Om het nog even anders en kort te verwoorden.

De huidige situatie is nu zo:
90 locaties
800 softwareinstallaties
90 mdb databases(per locatie 1)

in de nieuwe situatie willen we:
90 locaties
1 softwareinstallatie op de server (en die dan via XenApp aanbieden aan de gebruikers)
1 of 90 mdb databases op de server (de gegevens moeten van de locaties afgeschermd zijn)

[Rolfie]

Is de applicatie een web applicatie of niet?

Daarbij is het nog steeds niet erg duidelijk?

Hoe bepaald de applicatie bv waar de data zich bevind?

[jvalks]

Om kosten te besparen zou je ook eens Terminal Server kunnen overwegen... en denk aan je backup/failover...

[The Eagle]

MDB een database? I dont think so
MDB is een access bestand. Je hebt dus eigenlijk 90 min of meer identieke access applicaties draaien die je nu wilt centraliseren. Dat kan eigenlijk maar op 1 manier, en dat is de hele boel in een SQL server of ander _echt_ DBMS mikken, en je frontend daarop aanpassen. Zo niet, blijf je vermoedelijk met je 90 identieke applicaties zitten, al is het dan op 1 centrale server. Laat ze dan decentraal staan zou ik zeggen, stukje veiliger ook

[CodeCaster]

The Eagle schreef op donderdag 07 juni 2012 @ 15:02:
MDB een database? I dont think so
MDB is een access bestand. Je hebt dus eigenlijk 90 min of meer identieke access applicaties draaien die je nu wilt centraliseren. Dat kan eigenlijk maar op 1 manier, en dat is de hele boel in een SQL server of ander _echt_ DBMS mikken, en je frontend daarop aanpassen. Zo niet, blijf je vermoedelijk met je 90 identieke applicaties zitten, al is het dan op 1 centrale server. Laat ze dan decentraal staan zou ik zeggen, stukje veiliger ook

Als de applicatie met ODBC/DSN's werkt, kun je met een degelijk applicatieplatform prima per gebruiker de connectie naar de juiste database instellen, of eventueel de configuratie van de applicatie zélf per gebruiker instellen. Sterker nog, dit kan ook als de .mdb via een pad wordt opgevraagd, dan geef je de applicatie gewoon een netwerkschijf die per user naar de juiste locatie wordt gemapt.

Maar voor al deze informatie zul je toch bij de bouwer van de applicatie in kwestie moeten gaan.

[ Voor 8% gewijzigd door CodeCaster op 07-06-2012 15:08 ]

[PP90134]

Rolfie schreef op donderdag 07 juni 2012 @ 14:43:

Hoe bepaald de applicatie bv waar de data zich bevind?

Inderdaad, en daar zit ik nu ook over te dubben hoe ik dit voor elkaar krijg .

The Eagle schreef op donderdag 07 juni 2012 @ 15:02:
MDB een database? I dont think so
MDB is een access bestand. Je hebt dus eigenlijk 90 min of meer identieke access applicaties draaien die je nu wilt centraliseren. Dat kan eigenlijk maar op 1 manier, en dat is de hele boel in een SQL server of ander _echt_ DBMS mikken, en je frontend daarop aanpassen. Zo niet, blijf je vermoedelijk met je 90 identieke applicaties zitten, al is het dan op 1 centrale server. Laat ze dan decentraal staan zou ik zeggen, stukje veiliger ook

Ik kan helaas niet de database aanpassen aangezien ik de software niet kan aanpassen. Ik vrees dat dit een gevalletje onmogelijk is.

[Arcesilaus]

Kun je de MDB zelf ook niet aanpassen? Anders zou je linked tables naar een SQL server kunnen maken in de MDB...

[The Eagle]

Wellicht ten overvloede, maar wat mag een dergelijk geintje kosten? Een bedrijf / instelling met 90 locaties is nou niet echt klein te noemen. Voor zoiets zou ik toch een iets beter systeem als een access tool verwachten eigenlijk.

Heb je gekeken naar andere mogelijkheden, bijvoorbeeld de implementatie van een nieuw systeem icm een conversie? En wat zegt de leverancier van het spul zelf?

[Boss]

Sinds wanneer kan je een Access mdbniet aanpassen?
Of is het een stand-alone applicatie waarbij de ontwikkelaars ervoor gekozen hebben om mdbte gebruiken voor de data-opslag? Is er dan geen multi-user versie beschikbaar waarbij je de data op het netwek kunt zetten?

[Rolfie]

PP90134 schreef op donderdag 07 juni 2012 @ 15:07:
Inderdaad, en daar zit ik nu ook over te dubben hoe ik dit voor elkaar krijg .

Er zijn een aantal mogelijkheden:

1. Registry HKCU => Kan via GPO dan aangepast worden.
2. Registry HKCU => lastiger aan te passen. Maar kan naar een drive letter verwijzen die voor iedere gebruiker uniek is.
3. ODBC User => Kan dus per user aangepast worden
4. ODBC System => lastiger aan te passen. Maar kan naar een drive letter verwijzen die voor iedere gebruiker uniek is.
5. ini / config file => Apparte drive letter per gebruiker
6. vast path wat het zelfde is als het install path van de applicatie => Apparte drive letter per gebruiker

[CH4OS]

Zoals eerder gezegd, .mdb bestanden wil je niet in een productie omgeving voor een applicatie gebruiken. Zeker niet in een bedrijf wat zo'n 90 locaties heeft (en mogelijk een flink aantal gebruikers), dan kan het haast geen al te klein bedrijf zijn. Ik zou eventueel samen met de leverancier gaan zoeken naar oplossingen, lukt dat niet, dan overstappen (migreren) naar een ander pakket, waarbij de huidige omgeving geïmporteerd wordt in de nieuwe.

[Remco]

PP90134 schreef op donderdag 07 juni 2012 @ 12:55:
We gaan overigens waarschijnlijk XenApp gebruiken.

Iedereen gaat een beetje voorbij aan het feit dat de TS al een paar keer aangeeft dat hij de database en software niet kan wijzigen.

Als je wel Xenapp gaat gebruiken zou ik gewoon de verschillende appliciates naast elkaar zetten, en op Xenapp niveau laten bepalen vanaf welke lokatie de applicatie wordt opgestart (dit is wordt standaard ondersteund), en dan de juiste db daaraan presenteren.
Dit is iets waar Xenapp heel goed in is. Hoef je ook niet moeilijk te doen met weet ik veel wat.

[ Voor 14% gewijzigd door Remco op 10-06-2012 17:18 ]

[BertS]

CptChaos schreef op zondag 10 juni 2012 @ 12:42:
Zoals eerder gezegd, .mdb bestanden wil je niet in een productie omgeving voor een applicatie gebruiken. Zeker niet in een bedrijf wat zo'n 90 locaties heeft (en mogelijk een flink aantal gebruikers), dan kan het haast geen al te klein bedrijf zijn. Ik zou eventueel samen met de leverancier gaan zoeken naar oplossingen, lukt dat niet, dan overstappen (migreren) naar een ander pakket, waarbij de huidige omgeving geïmporteerd wordt in de nieuwe.

Beetje kort door de bocht misschien, die hetze tegen mdb
Het kan ook prima een franchise club zijn met 90 single users, waar mdb prima kan functioneren. of een andere vorm van decentralisatie (zelfstandig opererende professionals met eigen data)
Ik zie het in de praktijk nog zijn veel omgevingen prima en stabiel in gebruik, natuurlijk wel de kleinere omgevingen.

[The Eagle]

BertS schreef op maandag 11 juni 2012 @ 20:25:
[...]

Beetje kort door de bocht misschien, die hetze tegen mdb
Het kan ook prima een franchise club zijn met 90 single users, waar mdb prima kan functioneren. of een andere vorm van decentralisatie (zelfstandig opererende professionals met eigen data)
Ik zie het in de praktijk nog zijn veel omgevingen prima en stabiel in gebruik, natuurlijk wel de kleinere omgevingen.

Het zou kunnen, maar het kan ook zomaar van niet. Assumption is the mother of all fuckups

Ik wil eerst TS zijn business case wel eens horen: om wat voor omgeving(en) praten we, waarom wil je dit, wat is de onderliggende zakelijke rechtvaardiging om dit te doen, welke alternatieven qua oplossingsrichting zijn er bekeken, etc. Misschien zelfs wel hoeveel stakeholders er betrokken zijn.

Zomaar blind een oplossingsrichting ingaan is nooit eengoed idee namelijk

[ Voor 39% gewijzigd door The Eagle op 12-06-2012 14:23 ]