[C++ BCB6] Firebird / IB Database TIBTABLE screen update :?

[dexter07051982]

hallo,

Ik ben bezig met het ontwikkelen van een kassasysteem. Hiervoor maak ik gebruik van een centrale Firebird/Interbase database.

Als je nu je kassa dag en nacht laat draaien en deze de connectie met de database behoud (moet ook) kan ik de zojuist op het kantoor ingevoerde artikelen niet zien in mijn kassa. Deze worden wel in de database geset.

Als je de verbinding met de database verbreekt en weer opzet, kun je ze wel zien.
Ik vind dit zelf een zeer omslachtige manier.
Weet iemand hoe ik dit kan verhelpen op een manier dat ik niet de verbinding met de database hoef te verbreken?

Alvast bedankt voor jullie reacties,

Dexter07051982

(Het gaat hier dus niet om de netwerkverbinding maar de verbinden van het programma en de database)

[whoami]

Gebruik je transacties en commit je de transactie niet ?
Welk transaction isolation level gebruik je?

Hoe ga je met connecties om? Sluit je je connection object van zodra je het niet meer nodig hebt?

[dexter07051982]

whoami schreef op 27 februari 2004 @ 14:40:
Gebruik je transacties en commit je de transactie niet ?
Welk transaction isolation level gebruik je?

Hoe ga je met connecties om? Sluit je je connection object van zodra je het niet meer nodig hebt?

ik sluit de connecties niet als ik ze niet meer nodig heb.
Verder post ik ze wel en komen ze ook wel in de database te staan.

C++:

Db_Connect->Kleuren->Post();
Db_Connect->Kleuren->ApplyUpdates();
Db_Connect->Default_Trans->CommitRetaining();

hiervoor staat natuurlijk wat in welk veld moet komen.

Dit werkt allemaal prima.
als ik nadat ik de invoer heb gedaan het programma op een ander client opstart, (Zonder het op de eerste te sluiten (en de connecties gewoon open laat)) staan de velden namelijk wel op het scherm in de datagrid (in dit geval dan).

Nog wel een nieuwe vraag opgerezen. Wat is het transaction isolation level, geeft dit aan, en vooral waar is dat voor nodig.

[whoami]

Simpel gezegd:
Transaction isolation bepaald welke gegevens een andere sessie kan zien. Als je transaction isolation bv. op 'Read Uncommited' staat, dan kan sessie A de gegevens zien die sessie B heeft ingebracht maar nog niet gecommit heeft. (Niet aan te raden).

Maar nu snap ik ff niet meer wat je bedoelt:
Eerst zeg je dat je de gegevens niet kan zien die door een andere client zijn ingebracht, en nu kan je het wel?

[dexter07051982]

Ik kan ze wel zien als ik het progamma op de andere client later start dan dat ik de wijzigingen heb ingebracht (gecommit). Als het programma al op die andere client draaide zie ik de wijzigingen niet. Als ik dan het programma op die andere client opnieuw start zie ik ze dus weer wel.

Maar das natuurlijk niet handig om als er op kantoor een wijziging gepost wordt, ik eerst het programma moet afsluiten en dan opnieuw opstarten om deze wijzigingen te zien.

[whoami]

Ah, dat is logisch he.

De gegevens die je op je scherm hebt, zijn de gegevens die in de DB zitten op het moment dat je ze er uit gehaald hebt. Die worden natuurlijk niet automatisch gerefreshed.

[dexter07051982]

whoami schreef op 27 februari 2004 @ 15:18:
Ah, dat is logisch he.

De gegevens die je op je scherm hebt, zijn de gegevens die in de DB zitten op het moment dat je ze er uit gehaald hebt. Die worden natuurlijk niet automatisch gerefreshed.

ja, en hoe refresh ik deze data dan. Als ik de instelling op forced refresh zet werkt het niet. En ook niet als ik refresh aanroep van de TIBTABEL waar de DataSource aanhangt.

[kasper_vk]

Je voert dus gegevens invanaf client A, welke je vanaf client B niet kan zien, wanneer de connectie van B eerder is gestart dat die van A.

Een andere mogelijkheid dan die van whoami:

Ik neem aan dat je op B de gegevens opvraagd d.m.v. een query.
Commit je na die opvraag-query ook direct?

Doe je dit namelijk niet, dan kun je nadat A iets heeft gewijzigd gerust nogmaals de gegevens vanaf B opvragen, maar dan zie je de wijzigingen van A natuurlijk nog steeds niet. Omdat de database (vanwege serialiseerbaarheid & het isoleren van transacties) client B een consistente voorstelling wil geven van de database en wel precies die situatie waarin de database verkeerde op het moment van het begin van de transactie van client B. En die transactie begon dus al op het moment van de eerste query van B, voordat A de wijzigingen maakte.

[whoami]

Het heeft niets met transaction isolation te maken hoor.

Het is gewoon logisch dat je de nieuwe / aangepaste gegevens niet ziet op jouw scherm dat je een uur eerder geopend hebt.
Je kan natuurlijk wel ieder half uur ofzo automatisch de gegevens refreshen, of anders kan je misschien ook eventueel met een Observer pattern oid werken.

[ Voor 4% gewijzigd door whoami op 27-02-2004 16:00 ]

[kasper_vk]

dexter07051982 schreef op 27 februari 2004 @ 15:43:
[...]


ja, en hoe refresh ik deze data dan. Als ik de instelling op forced refresh zet werkt het niet. En ook niet als ik refresh aanroep van de TIBTABEL waar de DataSource aanhangt.

@Whoami: ik krijg dus de indruk, uit bovenstaande reactie van dexter, dat het wellicht geen kwestie is van het versen van de gegevens die op het scherm staan. Natuurlijk snap ik dat de gegevens bij de client niet spontaan op de hoogte zijn van wijzigingen. (zou wel verdomd makkelijk zijn, trouwens )

Maar goed: het zou nog steeds wel een kwestie van verversen kunnen zijn. Ik be benieuwd hoe het er bij Dexter voor staat.

[dexter07051982]

ja, oke.
maar dit vreet behoorlijk veel netwerkverkeer. is er geen optie dat ie automatisch refreshed of dat ik kan vragen om een refresh (refresh() werkt niet) zogauw als ik een scherm open.

[dexter07051982]

nog even wat extra info.

Ik programmeer via Borland C++ Builder 6.
Daar kan ik een IBDATABASE en een IBTABLE op een datamodule slepen. Aan de IBTABLE han ik dan weer een TDataSource. ik weet dus niet of dit wel met een querry gaat. zal waarschijnlijk wel zoiets dergelijks zijn, maar het kan wat mij betreft net zo goed de tabel zijn. (dacht alleen van niet anders zou ik de wijzigingen toch moeten zien).

[Verwijderd]

Interbase/Firebird ondersteund database events. HINT!

[Verwijderd]

dexter07051982 schreef op 27 februari 2004 @ 16:15:
nog even wat extra info.

Ik programmeer via Borland C++ Builder 6.
Daar kan ik een IBDATABASE en een IBTABLE op een datamodule slepen. Aan de IBTABLE han ik dan weer een TDataSource. ik weet dus niet of dit wel met een querry gaat. zal waarschijnlijk wel zoiets dergelijks zijn, maar het kan wat mij betreft net zo goed de tabel zijn. (dacht alleen van niet anders zou ik de wijzigingen toch moeten zien).

Sluit die tabel eens in je kassa en open hem weer nadat je wijzigingen hebt gedaan in de database.
Zijn de wijzigingen dan nog niet zichtbaar, dan ligt het waarschijnlijk toch aan de "transaction isolation level" van de kassa.

[ Voor 2% gewijzigd door Verwijderd op 28-02-2004 11:28 . Reden: typo ]

[dexter07051982]

als ik alleen de tabel na het invoeren close en weer open, dan werkt het niet.
Als ik de database open en close werkt het weer wel.

Dan nog wel even een vraagje. Hoe stel ik dat isolationlevel in. voor zover ik weet zag ik daarvoor geen methode bij de database, tabel en de transactie.

M.A.W. Heeft Interbase/Firebird dat wel?

[Verwijderd]

dexter07051982 schreef op 01 maart 2004 @ 09:11:
als ik alleen de tabel na het invoeren close en weer open, dan werkt het niet.
Als ik de database open en close werkt het weer wel.

Dan nog wel even een vraagje. Hoe stel ik dat isolationlevel in. voor zover ik weet zag ik daarvoor geen methode bij de database, tabel en de transactie.

M.A.W. Heeft Interbase/Firebird dat wel?

Je IBDatabase component heeft een property Params. Hiermee kan je allerlei instellingen meegeven.

Voor welke waarden je allemaal hier in kan vullen, moet je maar in de documentatie van Interbase kijken.

[kasper_vk]

dexter07051982 schreef op 01 maart 2004 @ 09:11:
...
Dan nog wel even een vraagje. Hoe stel ik dat isolationlevel in. voor zover ik weet zag ik daarvoor geen methode bij de database, tabel en de transactie.

...

Heb je al geprobeerd om een commit te geven na het opvragen van de gegevens? (Uiteraard alleen direct een commit geven wanneer je de gegevens opvraagd om alleen te bekijken en het opvragen dus een losstaande (trans)actie is.)

De transaction isolation level aanpassen klinkt namelijk als iets waar je later spijt van zou kunnen krijgen, omdat je in feite de door de client ervaren integriteit om zeep kan helpen (read uncommited lijdt bijvoorbeeld mogelijk tot dirty reads).

[dexter07051982]

kasper_vk schreef op 01 maart 2004 @ 11:36:
[...]

Heb je al geprobeerd om een commit te geven na het opvragen van de gegevens? (Uiteraard alleen direct een commit geven wanneer je de gegevens opvraagd om alleen te bekijken en het opvragen dus een losstaande (trans)actie is.)

Hoe bedoel je dat precies?

Als ik namelijk mijn venster open, open ik op het moment ook de connectie met de database en met de tabel. Verder gebruik ik dan een grid waar de gegevens in komen te staan. gekoppel aan een TDataSource.

Los van de qoute.

Wat betreft het werken met Events. ik kan het event nu wel opvangen, maar hoe ververs ik dan het scherm?. als ik namelijk na het event (die activeert het) de connectie met de database en de tabel verbreek en weer maak, loopt ie vast.

(maar wat daarvan de oorzaak is weet ik nog niet.)

[kasper_vk]

Sorry als je onderschat, maar ff voor de basis: je weet wat een commit (of abort) en wat een transactie is? En vooral: hoe een database (met transactie-support) 2 tegelijk lopende transacties behandelt?
Zo niet, dan zou ik dat dus eerst ff gaan uitzoeken, want dat is dus wel de minste vereiste om een multi-client DB-toepassing te gaan maken .

Ervan uitgaande dat dat gesneden koek voor je is:
Wanneer je vanaf het kantoor een artikel toevoegd en je commit die transactie (A), dan is (afhankelijk van het type scheduler in je DBMS) het resultaat alleen te merken voor transacties die later begonnen dan transactie A.

Wanneer je de kassa opstart en er allerlij acties mee uitvoert op je database, maar niet tussentijds commit, dan beschouwt Interbase al die acties als behorend bij 1 (heeeeele lange) transactie. --> Om de toevoeging van een artikel vanaf het kantoor te kunnen zien aan de kassa, zul je de lopende transactie aan de kassa dus eerst moeten afsluiten door een commit (of abort).

[dexter07051982]

ik gebruik commitRetaining() in plaats van commit. Dit omdat ik anders alle gegevens op het scherm kwijt ben. Naar mijn idee mag dit verder niks uitmaken (als ik het verschil goed heb begrepen).

[kasper_vk]

Ik heb gezocht (Google) en tot dusver kom ik tot de conclusie dat het verschil tussen commit en commitRetaining is:
- met commit sluit je de transactie af
- met commitRetaining sluit je de transactie niet af

De oplossing lijkt mij duidelijk: commit gebruiken i.p.v. commitRetaining

Zie ook: een topic op NLDelphi.com over het verschil tussen die 2.

Nog een nuttig linkje: Writing to the InterBase API using Delphi - IBPhoenix.com, ongeveer halverwege de pagina staat uitgelegd wat de commit en de commitRetaining doen. De commitRetaining is volgens mij meer bedoeld om tussentijds te kunnen 'saven' bij een hele lange transactie.

[ Voor 28% gewijzigd door kasper_vk op 01-03-2004 14:06 . Reden: onderste linkje toegevoegd ]

[dexter07051982]

commit() gebruiken lost het probleem niet op.

Ik kan nog steed mijn gegevens niet updaten op het andere scherm zonder eerst de verbinding te sluiten en opnieuw te maken.

Dit gebeurt er bij het onShow()
Db_Connect->Database->Open();
Db_Connect->Merken->Open();

Dit gebeurt er bij onClose()
Db_Connect->Merken->Close();
Db_Connect->Database->Close();

Als ik dit doe (direct achter elkaar ) in het gedeelte waar ik het event opvang gaat ie hangen. (moet je me (nog) niet vragen waarom). Als ik refresh aanroep na Open() van de tabel, werkt het ook niet. Ik kan dus na het event nog steeds niet op de andere client zien wat ik heb veranderd. het event wordt gegenereerd in de database door de triggers, after update, after instert en after delete.

Het event wordt wel goed opgevangen want ik kan wel in bijde een messagebox laten zien.

[kasper_vk]

En, ben je er al uit?
Zo ja, wat is de gebruikte oplossing?

[dexter07051982]

Sorry voor de late post, maar kwam er net een paar dagen geleden achter (en toen was de adsl-splitter stuk)

Als je events gebruikt in je database, en deze laat sturen bij een verandering. Je kunt dan het event opvangen en daar een commit doen als de bijbehorende transactie actief is. Daarna open je dan de dataset. Als de transactie niet actief is hoef je alleen de dataset maar te openen.