Bazy danych i 3 pytania

Siema.

Napisałem w Delphi program bazodanowy "serwer" z plikiem bazodanowym i program "klient" bez tego pliku.

Używam sobie komponentów IBX, bo baza jest wykonana w IBExpert, pod serwer Firebird 2.1.3.

Teraz mam komponenty: IBQuery, IBDatabase, IBTransaction i Datasource

W komponencie IBDatabase od programu "serwer"mam tak:
Connection - Remote
Server - 127.0.0.1
Port - TCP
Database - C:\Serwer\DATA.GDB
User i hasło - standardowo
Login Prompt - odznaczony

Więc ścieżka w IBDatabase1.DatabaseName:=127.0.0.1\DATA.GDB

Wiadomo, że teraz sprawdzam to tylko na swoim kompie i ten adres będę musiał zmieniać jak będę chciał z tym wyjść na zewnątrz sieci, a Klienci ze swoim programem "klient" będą musieli jakoś odczytywać mój adres zewnętrzny (dobrze rozumiem?).

Identycznie mam w programie "klient", czyli powyższe ustawienia tylko znajduje się na dysku D, czyli D:\Klient, ale już bez pliku bazodanowegoDATA.GDB.

Oczywiście jak zacznę się bawić w dodawania rekordów z poziomu serwera czy klienta, to tabelę odświeżam poprzez SELECT * FROM.....

NA CZYM PROBLEM POLEGA??
Jeśli dodaję/edytuję/usuwam rekord np. z poziomu programu "klient" to jak teraz odświeżyć tabelę w programie "serwer"?? I na odwrót.

Próbowałem użyć komponentu UpdateSQL i tam w Insert dać SELECT * FROM...ale to nic nie daje.

1. Jak odświeżyć bazy w kliencie i serwerze po operacjach?
2. Czy macie jakiś pomysł na połączenie się klientów do serwera jeśli on ma zmienne IP zewnętrzne? Myślałem coś o FTP, aby wysyłać klientom do Edit adres serwera. :)

Szukam na google o tym odświeżeniu tabeli na google zdalnie jak i lokalnie.

Hmm może nasłuchiwać pojemność pliku bazy w bajtach i gdy się zmieni to dawać w programach SELECTa? hmm takie dzikie jakieś. ;]

zwykle praca z sewerowymi bazami danych sprowadza się do jednego - wydaje się im polecenia, one oddają wynik.
Serwer nie musi informować Cię o zmianach wykonanych przez innego zalogowanego użytkownika.
Zwykle to na aplikacji korzystającej z architektury klient - serwer spoczywa ciężar odświeżania danych.
Można to oczywiście odwrócić, ale dziwnym by było, gdyby przy źle napisanym programie (gdy np. masz otwartą tabelę i wprowadzasz dane - bo tak łatwiej - nastąpi odświeżenie zawartości tabel) ... Z misia - sprawdzić, czy nie ksiądz ...

poczytaj o eventach w FB
BTW takich rzeczy się po prostu nie robi w normalnych programach - dajesz userowi przycisk refresh i tyle

a co zmiennego ip tp już jakiś czas temu ktoś mądry wpadł na pomysł i wymyślił coś co się zwie Dynamic Domain Name System

dajesz userowi przycisk refresh i tyle

Czyli może być sytuacja że pracownik może wykonać przypadkowo operacje na nieistniejących rekordach, chyba każdy w pracy chciałby tego uniknąć, no ale jeśli to jedyna metoda i naprawdę nikt na świecie nie wie jak odświeżać bazę to trudno, będe musiał to zastosować.... ;]

Jesli chodzi o zmienne IP, to wydaje mi się że to już będzie mniejszy problem niż samo odświeżanie bazy. ;]

Myślę że operacja na nieistniejących rekordach nie jest taka bardzo niebezpieczna. To jak kradzież nieistniejącego samochodu.

Myślę że są na świecie ludzie którzy wiedzą jak odświeżać bazę ... poczytałeś o eventa'ch jak rzekł misiek ?

Masz jeszcze bliżej pod oczy

http://firebirdsql.org/doc/whitepapers/events_paper.pdf

A może wydrukować i wysłać pocztą ?

b

Zrobiłem już wszystko wczoraj. Temat do zamknięcia.
Tego pdfa czytałem już dawno heh.

A może wydrukować i wysłać pocztą ?

Chętnie.

Ksiądz napisał(a)

Tego pdfa czytałem już dawno heh.

Ze zrozumieniem tekstu ?

Ksiądz napisał(a)

A może wydrukować i wysłać pocztą ?

Chętnie.

Poszło UPS'em

b