N & Others,
> If you (or anyone else for that matter) want a MSSQL vrs IB
> document, email me at work ([EMAIL PROTECTED]), and I'll fire it over.
Its a .pdf
Thanks, but you have already sent me that document. It was rather large on
marketing hype and low on tech stuff *grin*
In reading your mail I do have a couple of problems / questions.....
> server every "X" seconds and pick up changes. As long as you dont
- 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.
> Run Local IB on the GFX machines, with a seperate thread/app
> replicating the data from the main box/boxes, which would be a normal
install of IB
> server. (cuts down your costs, see!)
- 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
OK. So based on your recommendations you would:
1. Have IB Server for the master(s)
2. Have Local IB for the slave(s)
And to do replication:
1. Use Thread etc....
Discounted based on additional complexity (above). Also the Local IB would
not accept incoming DB connections so this info would have to go to a local
process which would then have to make the changes locally to the slaves
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??
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??
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??
- 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.
- Can you do the following sql off server1 --
server2.login.server2DB.server2StoredProc??
Nic, can you also explain licencing for 6.0 in terms of Linux?? Is it
totally free?? Also do you know off hand if there is any support from PHP,
Perl, Apache for Interbase on Linux??
TIA
------------------------------------------------------------------------
--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 07:02
> To: Multiple recipients of list delphi
> Subject: Re:[DUG]: Interbase Issues & Questions.....
>
>
>
> Donovan,
>
> If you (or anyone else for that matter) want a MSSQL vrs IB
> document, email me
> at work ([EMAIL PROTECTED]), and I'll fire it over. Its a .pdf
> I wrote a while back.
> I'm not going to rant on MSSQL _again_, 'cos I think everyone
> here knows my
> opinion on the topic.
>
> >This sounds rather complex, but generally the:
> >
> >- Frequency of adding new records is not high. Say a record
> every couple of
> >seconds
> >- Frequency of amending records is not high. Say a record every couple of
> >seconds
> >- Retrieval of data for graphics purposes is rather frequent.
> Can be every
> >second
> >- Datasets are small. Peaks at about 2000 records for current game
> >information. (Historical data is more, but as a rule this is not accessed
> >all that frequently for graphics purposes)
>
> Interbase should be able to handle this without any problems. If
> you have multiple
> reads and writers, make sure you get your transaction handling
> right - I've had a
> few problems with this, tho its just as likely to be my crap
> programming :) You just
> have to make sure you dont so an update and leave the transaction open....
>
> >We have got by at present, using Paradox, but we are starting to
> "outgrow"
> >it and have a need to move to Interbase for:
> >
> >- Speed
> >- Data Integrity
> >- Referential Integrity etc. etc.
>
> Good reasons. :)
>
>
> >In making the move we would also like to increase data redundancy. At
> >present we have a central database (essentially, we also have
> copies so this
>
> <SNIP>
>
> >Entry box as the master and then carry on from there.
>
> One idea _could_ be to run local IB on the data generators - DONT
> count on the
> servers crashing - it doesn't happen that oftern :) In my
> e-commerce app, the
> MTBF is about a week, and I _know_ thats my code thats causing it
> - but its easier
> to reboot the machine (NT) every few days than fix the bug, if I
> can find it. I know
> of DB's that have been up for months/years (definatly months
> atleast) with no
> problems.
>
> ... oops, back ontopic.
>
> Run Local IB on the GFX machines, with a seperate thread/app
> replicating the data
> from the main box/boxes, which would be a normal install of IB
> server. (cuts down
> your costs, see!)
>
> or just run it all from one machine :) Its not much of a resource
> hog (16-20meg
> under moderate load with 5-10 connections)
>
> Another option would be to use the IB6.0 replication that has
> been back-ported to
> 5.6 by Paul Beach (now ex-Interbase). I dont know if we can give
> it away, tho I
> dont see any reason why not - I'd have to chack if you are
> interested. I think
> doing it yourself would be better - you then have more control over it.
>
> >In order to do the replication we could:
> >
> >1. Based on our data loads etc, I believe we could have triggers
> that would
> >call stored procedures on the "Master" that would apply the
> changes to each
> >of the "Slaves" in turn
>
> Well, you could have triggers that wrote a record to an 'update'
> table saying "table
> BLAH, key FOO was changed" then use that for the replication on
> the clients. My
> flatmate uses that in his section of the project he just finished (?)
>
> >2. Use the "Shadow" database option to replicate the data??
>
> Nope, thats just accross disks. Sorry.
>
> >3. Use some other mechanism??
>
> See above.
>
> >I am leaning towards 1. It would mean that we have an Interbase Server on
> >each machine on our LAN, but is there another / better way??
>
> Not really. I think you have 2 options:
>
> 1) put IB on a server somewhere, either dedicated (needed if you
> run only 95,
> which you dont) or just on an otherwise low-use machine (you can
> put it on a high-
> use machine, but it increases the risk)
>
> 2) put IB on all the machines, and have a process on each machine
> poll a main
> server every "X" seconds and pick up changes. As long as you dont
> do a connect-
> getdata-disconnect-connect-getdata-disconnect cycle, it should be
> pretty fast.
> Good option for redundancy, tho its a more EXPENSIVE option.
>
> >One finaly caveat. As we have a substantial investment in NT
> Workstation out
> >in the field, as well as the fact that we don't want any *special* (read
> >"server type") machines this would all have to happen using NT
> Workstation.
>
> IB works on 95, 98 (not recommended tho), NTWS, NTS, NTAS, NTDCS,
> it works
> on Win2K, tho its not 'certified', Linux, Novell, Solaris, etc
> etc etc. Lots of choice.
>
> I personally like the Linux option. Its quick, reliable as hell,
> easy to install (both
> Linux and IB - IB it a total no-brainer), and VERY fast. NT works
> just fine tho.
>
> Nic
> (In this case, with his Inprise New Zealand sales hat on)
>
> --
> Nic Wise - Human (just)
> ph: 09.277.5309 / 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
