N,
This is consolidated from your various posts.......
- Have ONE central server
Agreed
- IB can not do server2.login.server2DB.server2StoredProc BUT instead of
using triggers / stored procedures to do this we could use TIBEvents to get
round this.
So assuming we use TIBEvents we could then have IB Server running on the
master(s) and Local IB running on the slaves as those apps would receive an
event from TIBEvents and make the change locally. However (Help is not
clear) TIBEvents allows only 15 events per component. What is an event?? Is
it:
- UPDATE SomeTable and this relates to all updates OR
- Ev1: UPDATE Table1, Ev2: UPDATE Table2 etc.
[Other Post]
Dont take this the wrong way, but surely writing a solid, tested,
working app would solve these problems? If you write and test your code
so it doesn't crash, and use a database that doesn't crash or corrupt
(ie, not paradox or Access), then having it fail is NOT an option??
No offence taken *smile*. Not sure I understand. I do want to write a solid
app and it will be well tested etc. etc. However if I can get away with
doing what I am proposing at the top of this mail and not going MIDAS, nTier
I would be happier......
------------------------------------------------------------------------
--Donovan
Donovan J. Edye [www.edye.wattle.id.au]
Namadgi Systems, Delphi Developer
Web: www.namsys.com.au E-Mail: [EMAIL PROTECTED]
Voice: +61 2 6285-3460 Fax: +61 2 6285-3459
TVisualBasic = Class(None);
------------------------------------------------------------------------
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Nic Wise
> Sent: Wednesday, 19 January 2000 10:08
> To: Multiple recipients of list delphi
> Subject: Re: [DUG]: Interbase Issues & Questions.....
>
>
> > Thanks, but you have already sent me that document. It was
> rather large on
> > marketing hype and low on tech stuff *grin*
>
> Fair enough. That was kinds the market I was aiming for with it.... :)
>
> > In reading your mail I do have a couple of problems / questions.....
>
> > - Doing a poll every couple of seconds is no good. As we are
> doing real time
> > TV graphics so changes made need to replicated almost instantaneously as
> > there is no point in bringing up a score card that does not
> have the latest
> > player scores etc.
>
> you you will _have_to_ run it off one server. Period. Have a look atht
> eIB Event Alerter component - it should allow callbacks on when a table
> has changed.
>
> > - I would like to steer away from having a seperate thread do a TCP
> > replication / synchronize because:
> > * Something else that could break, additional complexity
> > * Doing it with a trigger means that if nothing does
> happen for 10 secs
> > then nothing gets done. A thread
> > may have tried 5-10 times to do replication
>
> Fair enough.
>
>
> > 2. Use Donovan's trigger method
> >
> > If we have Local IB running on the slaves we would have a
> problem as Local
> > IB does not support incoming network connections. So slaves
> would have to
> > run full IB servers. I assume that on server1 you could make a call to a
> > stored procedure on server2 in a particular database??
>
> Nope, you can't do that, AFAIK.
>
> > 3. Use 6.0 Replication technology ported to 5.6
> >
> > Is it supported?? How solid is it?? Does it replicate on a
> record, by record
> > basis?? Or does it do things on a DB by DB basis?? Is it suitable to get
> > __real time__ data concurrency??
>
> No replication will work with realtime conncurrency - thats why you have
> 1 DB machine/process and N clients. Replication is NOT a good solution
> to any problem, except if you do it on a time-period basis over
> something slow like a WAN.
>
> > Another couple of things that concern me about IB, and I am
> sure that they
> > are due to my ignorance!!
> >
> > - Does DB size grow dynamically as in SQL 7?? Or are you forced
> to create a
> > DB for a specific size and then expand it from time to time??
>
> IB has had this since (atleast) 4.2. Also, you dont have a log, so no
> having a massive log file bloat out on you.
>
> > - What GUI admin tools are there for the server?? I have the
> problem that
> > these machines will be out there, travelling all around the
> country out of
> > my control and some techie will have to do backups etc.
>
> to backup:
> gbak -b -user sysdba -pass masterkey server:pathto/file.gdb
> somelocalfile.gbk
>
> the server can be running normally when you do this - you dont have to
> take it offline to get a decient backup.
>
> You can also do this via the GUI. Its about the same, tho its graphical.
>
> > - Can you do the following sql off server1 --
> > server2.login.server2DB.server2StoredProc??
>
> Nope, not AFAIK. Someone may want to correct me tho.
>
> > Nic, can you also explain licencing for 6.0 in terms of Linux??
>
> Nope, I can't - nothing has been announced yet EXCEPT the intention to
> opensource it. The US needs to decide on HOW they are going to do it
> (GPL, LGPL, proprietry etc) first.
>
> 5.6, which is the current release, is (AFAIK) not going to be open
> sourced, tho it will continue to be sold, supported, maintained etc.
>
>
> > Is it
> > totally free??
>
> Very unlikely. OpenSource != free. Never has.
>
> >Also do you know off hand if there is any support from PHP,
> > Perl, Apache for Interbase on Linux??
>
> I have on idea about PHP or Perl, but there are JDBC drivers, and native
> client drivers available. Mark Derricutt ([EMAIL PROTECTED] if he's
> not here already) would be the man to ask.
>
> Oh, and why would apache support it? Its a web server......?
>
>
> N
> --
> Nic Wise - Chief SCUD Launcher - Inprise/Borland New Zealand
> wk: 09.481.9999 x9753 cell: 021.676.418
> em: [EMAIL PROTECTED]
> ------------------------------------------------------------------
> ---------
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
>
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
