And if you want an even more extreme point of view on the topic than Nic's
yes its possible) then talk to me. I did a thorough review of SQL Server
just 3 months ago including lengthy discussion with MS Guru's on the
subject. In Summary dont waste time - go straight away to Interbase - a
porpper database which is now open sourced.
-----Original Message-----
From: Nic Wise <[EMAIL PROTECTED]>
To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
Date: Wednesday, 19 January 2000 9:04 AM
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
