[VB6]Planbord ontwikkelen

[pkouwer]

In het kader van het ontwikkelen van een planbord/-systeem het volgende:

Het systeem is bedoeld om het plannen van personeel eenvoudig en gebruiksvriendelijk te maken. Het bestaat uit twee delen : front-end en back-office.

Front-end is bedoeld als weergave. Op een monitor komt een overzicht te staan met de planning voor een x aantal weken, voor alle monteurs. Verder kan hier niets aangepast worden (in eerste instantie althans). Er dient real-time informatie weergegeven te worden;

Back-Office is bedoeld voor de kantoormedewerkers om de monteurs dus in te plannen. Verdere systeeminstellingen gebeuren ook op deze plaats.

Als database maak ik een keuze tussen MySQL en MS-SQL omdat MS-Access en MSDE niet voldoen, te weining concurrent users of te grote database. Dit is het probleem niet.

Punt van discussie is het real-time bijwerken van het planbord, de front-end. Ik kan het op twee manieren oplossen: winsocks gebruiken, als de back-office iets wijzigt, ook de front-end aanpassen, of een timer, elke x minuten/seconden checken en eventueel bijwerken.

Wat is jullie ervaring/mening hierin.

[djluc]

De Timer is gewoon enorm eenvoudig te implementeren. Als deze niet wordt gebruikt is dat vaak alleen maar omdat het "echt" realtime moet gebeuren. In andere gevallen is een timer gewoon ideaal imo.

[Verwijderd]

Het nadeel van een timer bij veel concurrent users is, dat alle clients om de zoveel tijd gaan checken of er misschien iets is gewijzigd. En zo ja, dan gaan ze allemaal de nieuwe data ophalen. Dat kan nogal wat extra netwerk traffic en database access veroorzaken, en het is lastig om bij te houden wat er sinds de vorige check is gewijzigd, en of die wijzigingen voor die client interessant zijn.

Stel, je bent aan het plannen voor september, er er wordt iets gewijzigd voor juni. Dan hoeft jouw client niet te refreshen, en hij hoeft zelfs niet te weten dat er in juni iets veranderd is... Dat is op te vangen door niet bv. alleen een update-tellertje bij te houden, maar een uitgebreidere log op de wijzigingen, maar met zeg 50 users die druk aan het wijzigen zijn kan die log aardig uit de klauwen lopen, en kan de controle van die wijzigingen aardig belastend worden. Zeker wanneer je in de buurt van 'realtime' wilt komen (elke minuut een check bijvoorbeeld).

Bij onze (hotel-)software hebben we om deze reden een EventBroker service geschreven. Deze draait centraal in het netwerk, en doet maar een paar simpele dingen:

- Iedere client meldt zich aan bij die service, en geeft aan in welke categorieen 'ie geinteresseerd is (een kassa in de bar zal het boeien of een hotelkamer is schoongemeld, maar het hoofd van de huishouding wil dat wel graag direct weten).

- Bij iedere wijziging sturen de clients een event naar die service, met de noodzakelijke informatie. Afhankelijk van het type event is dat meestal iets van reserverings- of kamernummer, begin- en einddatum, etc.

- De EventBroker stuurt dat event vervolgens 1-op-1 door naar alle aangemelde clients die hebben aangegeven dat ze geinteresseerd zijn in dat type event.

- De clients contoleren vervolgens of dat event voor hun van belang is, en zo ja, dan verversen ze de data. Als je bv. een groepsreservering voor juni aan het behandelen bent, en je krijgt door dat er iets in de kamerbeschikbaarheid van september is gewijzigd, kun je 't event gewoon negeren.

Ik weet 't, 't is geen rocket science, maar wanneer je die broker en de verschillende clients goed op elkaar afstemt, is het qua performance een aantal klassen beter dan een polling mechanisme.

[pkouwer]

hier zit ik inderdaad ook aan te denken. Het centrale planbord (alleen voor weergaven) haalt bij de start-up de data op uit de database, en plaatst zit in een grid. Iedere wijziging door één der planners, zorgt voor een event bij zowel het planbord, als bij de andere planners. Alleen de gewijzigde data dient te worden bijgewerkt/toegevoegd etc.

Als database zit ik sterk te denken over MySQL, maar hoe gaat hij om met recordlocking. We hebben in totaal zo'n 12 users, concurrent wel te verstaan.

[helder moment]
ik zit me te bedenken, dat als ik een service maak (TCP/IP-socket), kan ik volgens mij volstaan met 1 database-connectie. De planners doen dit via de service, toch ??

[/helaas, einde helder moment]

[ Voor 19% gewijzigd door pkouwer op 18-02-2005 08:17 ]

[P_de_B]

12 users is een makkie voor MSDE, concurrent users zijn die users die simultaan op de database werken. Alle 12 gebruikers zullen nooit tegelijk op de database een query uitvoeren.

Over de geschiktheid van MySQL voor kritische applicaties verschillen de meningen nogal, ik ben echter van mening dat o.a. referentiele integriteit en transacties zeer belangrijk zijn voor een database en dat een RDBMS dit moet ondersteunen.

[OZ-Gump]

12 users is een makkie voor MSDE, concurrent users zijn die users die simultaan op de database werken. Alle 12 gebruikers zullen nooit tegelijk op de database een query uitvoeren.

En ook al zouden er wel 12 concurrent users zijn: de versie van MSDE die momenteel verkrijgbaar is wordt afaik stabiel gezien tot 20 concurrent users. Zelfs dan zou er dus geen probleem zijn...

[P_de_B]

OZ-Gump schreef op vrijdag 18 februari 2005 @ 08:57:
[...]
En ook al zouden er wel 12 concurrent users zijn: de versie van MSDE die momenteel verkrijgbaar is wordt afaik stabiel gezien tot 20 concurrent users. Zelfs dan zou er dus geen probleem zijn...

Het gaat om gelijktijdige workloads niet om users:

quote: http://msdn.microsoft.com...k/html/msde2000webapp.asp

Understanding the Workload Governor

All versions of SQL Server 2000 (including MSDE 2000) support up to 32,767 connections per instance, assuming you have sufficient system resources. Each instance supports up to 32,767 databases. Although the full version of SQL Server 2000 supports databases up to 1,048,516 TB in size, MSDE 2000 databases are limited to 2 GB each. More importantly for your application designs, MSDE 2000 employs what is known as a concurrent Workload Governor. The effect of the governor is to slow certain operations down by stalling user connections for a few milliseconds whenever there are more than eight concurrent operations. Some system-generated events in the database engine count against this eight-operation limit, so the governor may kick in even when your application code requests fewer than eight operations. The key is concurrent operations, such as executing a query. This is not the same as concurrent users. In most applications, there is a certain amount of user "think time," where a live connection to the server exists, but the user is not actually performing a task that accesses the database. The actual number of concurrent users can be much higher. For some applications, MSDE 2000 is not able to produce performance figures that satisfy your users. At that point, you'll need to consider upgrading to SQL Server Standard or Enterprise Edition.

En nog iets uitgebreider: http://msdn.microsoft.com...rchitec/8_ar_sa2_0ciq.asp

Hierin staat o.a. dat je in het event log kunt zien hoe vaak de limiet is bereikt. Je zou dus kunnen testen, als er de limiet nooit of nauwlijks bereikt wordt heb je geen problemen met MSDE.

[ Voor 8% gewijzigd door P_de_B op 18-02-2005 09:05 ]

[pkouwer]

ok, ik wist niet beter of MSDE kan 5 concurrent users aan. Maar ik denk dat ik voor de oplossing met Winsock kies, anders moet ik toch iedere keer een database aanroep doen. Tevens kan ik een broadcastbericht zenden als er iemand een wijziging heeft doorgvoerd, of hebben jullie een andere mening.

[pkouwer]

de basis is inmiddels gelegd en het project vordert naar wens. Bij de uitdaging waar ik nu tegenaanloop, zou ik graag wat meningen horen. Het gaat over het vullen van mijn flexgrid. Ik het een tabel planning met een aantal velden, w.o. startdatum, einddatum en tekst. Deze, variabale, periode wil ik in het flexgrid markeren'/vullen met het veld tekst. Ik heb van link-naar-rechts de namen van personen, en van boven-naar-beneden, een zes-tal weken gevuld. De eerste kolom (col=0), is gevuld met de tekst: ma 21-02. Wat is nu de eenvoudigste wijze om het grid te vullen ?

[sopsop]

P_de_B schreef op vrijdag 18 februari 2005 @ 09:01:
[...]


Het gaat om gelijktijdige workloads niet om users:


[...]


En nog iets uitgebreider: http://msdn.microsoft.com...rchitec/8_ar_sa2_0ciq.asp

Hierin staat o.a. dat je in het event log kunt zien hoe vaak de limiet is bereikt. Je zou dus kunnen testen, als er de limiet nooit of nauwlijks bereikt wordt heb je geen problemen met MSDE.

Bij mijn vorige werk hebben we geprobeerd om de rem op de MSDE te krijgen door met 15 man tegelijk data uit MSDE op te vragen, te wijzigen en toe te voegen, met meerdere connecties. We hebben 'm een uur lang flink mishandeld en er was (bijna) geen sprake van vertraging.

Een flinke literatuurstudie (google) leerde ons ook dat er melding werd gemaakt dat 'de rem' bestond, maar dat waren allemaal referenties aan de manual van MSDE. Nergens was iets te vinden van een proefondervindelijke constatering van die rem. Onze voorzichtige conclusie was dat de beschreven beperkingen van MSDE alleen merkbaar waren bij de maximale tabel en database grootte, maar niet in het aantal concurrend users/connecties/workloads. Nadeel van die conclusie is dat je er later problemen mee kunt krijgen als MS de beperkingen wel strict gaat implementeren.

[FendtVario]

pkouwer schreef op donderdag 17 februari 2005 @ 19:18:
Punt van discussie is het real-time bijwerken van het planbord, de front-end. Ik kan het op twee manieren oplossen: winsocks gebruiken, als de back-office iets wijzigt, ook de front-end aanpassen, of een timer, elke x minuten/seconden checken en eventueel bijwerken.

Is het niet mogelijk om via een Trigger in de database een signaal te sturen naar alle aangemelde clients. Ik weet dat Interbase dit kan maar hoe en of MS-SQL dit kan geen idee, MySQL volgens mij niet. Op het moment dat de clients het event krijgen kunnen ze beslissen of de data ververst moet worden. Is dit niet mogelijk dat zou ik kiezen voor een oplossing zoals Afterlife heeft aangedragen.

[pkouwer]

in principe heb ik nu een soortgelijk oplossing dus.

iemand nog een idee over het vullen van het grid ??

[Verwijderd]

Is het niet mogelijk om via een Trigger in de database een signaal te sturen naar alle aangemelde clients. Ik weet dat Interbase dit kan maar hoe en of MS-SQL dit kan geen idee, MySQL volgens mij niet.

Bij mijn weten zijn InterBase en FireBird de enige databases met zo'n geintegreerde event alerter (en dat werkt verdraaide handig!). Misschien zijn er wel meer, maar dan ken ik ze niet.
Bij MSSQL is het technisch wel mogelijk door een trigger een stored proc aan te laten roepen die TCP/IP pakketjes verstuurt naar de overige clients, maar dan moet je die stored proc toegang geven tot 'low level' routines die buiten de scope van de database vallen. En een hoop systeembeheerders zijn daar (terecht) niet zo happig op...
MySQL kan 't voorlopig doodgewoon nog niet (support voor stored procs en triggers ligt nog op de tekentafel).

iemand nog een idee over het vullen van het grid ??

Ik heb nauwelijks ervaring met VB, en al helemaal niet met flexgrids, maar die dingen hebben toch wel een event/listener/whatever waarop je kunt bepalen welke cell gepaint moet worden?
Zo ja, laat 'm kijken naar een onderliggende (object-)structuur waar de gegevens in worden bijgehouden.
In XML zou zo'n structuur er ongeveer zo uit kunnen zien:

XML:

<Dates> 
    <Date value='2005-02-21'>
        <Users> 
            <User name='Jan' position='1'>
                <Appointments>
                    <Appointment startTime='09:00' endTime='11:00' description='Werkoverleg' />
                    <Appointment startTime='12:30' endTime='14:00' description='Lunch met directie' />
                    <Appointment startTime='14:30' endTime='18:00' description='En nu aan het werk...' />
                </Appointments>
            </User>
            <User name='Piet' position='2'>
                <Appointments>
                    ...
                </Appointments>
            </User>
        </Users>
    </Date>
    <Date value='2005-02-22'>
        ...
    </Date>
</Dates>

Je weet welke datum bij welke rij hoort, en welke kolom bij welke persoon, dus is 't in principe gewoon een kwestie van de bijbehorende gegevens ophalen en tonen. Toch?

[ Voor 11% gewijzigd door Verwijderd op 22-02-2005 21:48 ]