Big database

[jorge novoa]

ok. all you people told me about the ib benefits, but my personal experiencie it`s a little bit different, because i had been experimented often db corruptions(interbase 6.0) and i'm talking about stand alone apps., and that is not a good point to ib. For examle i have an db app. runing ib 6.0 and db corrupts each 1 or to 2 months max. and i never knew why db its corrupted. that comp. ran win98(not ever more), and the user never gave me reasons enough to determinate why db was corrupt.
In another example(no network app. too), talking with the user i notice that the electricity went out when they used the app..
I have to considere the points above very seriously to get a determination of the best db server.
REgards

[Bill Todd]

You were almost certainly running with forced writes off which is an
invitation to corruption in an environment where the machine running IB
can crash. Your experience is not typical if IB is configured properly
for its environment. In addition, the journaling feature in IB 2007
dramatically reduces the probablility of unrecoverable database
corruption.

--
Bill Todd (TeamB)

[Loren Szendre]

jorge,

I have hundreds of IB 6.0 (open source) installed through North America,
and have only had two corruptions over 5 or 6 years, both due to
hardware failure. If you are getting corruptions, you probably had
forced writes turned off. IB 7.5 is way better, but IB had always
performed amazingly well for me, in regards to stability/resistance to
corruption.

Loren

[spam}@westonmuir.com Steve Weston]

Jorge,

There are several things for you to consider when running an SQL database --
IB or whatever:

1) Run the current (or near current release) of the database. IB 6.0 is
pretty old. It had several updates. IB 7 also has had several updates. So,
there's no excuse for running IB 6.0 today.

2) Win98 is not a server OS -- never was intended to be. It was replaced
many years ago by Win XP. Win98 is no longer supported by Microsoft. Why
should you still support it?

3) Any database will corrupt unless you take prudent precautions. Use hard
writes. Use a UPS. Use a modern OS designed to be a server OS. Make backups.
Test your backups. Use the database maintenance functions to scan for
problems. Test your storage devices periodically. Don't let non-InterBase
software touch your database (like generic backup apps).

We have clients across the USA that have been running our apps using
InterBase for years. So far there has been only one case of database
corruption -- and that was caused by a failing hard disk. We continue to
recommend InterBase without reservation as extremely reliable for large and
small installations (and we have some huge installations with very heavy
workloads).

HTH

--
Steven S. Weston
Weston & Muir LLC (http://www.westonmuir.com)
The Banking Software Specialists

[Jonathan Neve[Microtec]]

Steve Weston wrote:

> Jorge,
>
> There are several things for you to consider when running an SQL
> database -- IB or whatever:
>
> 1) Run the current (or near current release) of the database. IB 6.0
> is pretty old. It had several updates. IB 7 also has had several
> updates. So, there's no excuse for running IB 6.0 today.

Well there's always the old "if it ain't broke, don't fix it" addage
(though admittedly, it may not apply here, since his database seems to
qualify as "broke"). We have several customers still running our
software against an IB 5.0 server. We realize that there would be
advantages to upgrading, but such advantages are not always immediately
apparent to the customer, and furthermore, it would imply a
considerable amount of work to upgrade all the queries in our
application to work correctly with newer versions (or at least a good
deal of testing to be sure there are no issues). And since, in our
case, we have never, ever had a database corruption with IB 5... there
isn't that much motivation to upgrade.

> 2) Win98 is not a server OS -- never was intended to be. It was
> replaced many years ago by Win XP. Win98 is no longer supported by
> Microsoft. Why should you still support it?

Again, Microsoft not supporting the OS hardly means that we can refuse
to support customers who still use it, or who see no good reason to
upgrade. I do agree however that it's a terrible choice for a database
server OS.
--
Best regards,
Jonathan Neve
_______________
CopyTiger - advanced database replicator for Interbase/Firebird!
Web : http://www.microtec.fr/copycat/ct
_______________________________________
CopyCat - database replication components for Delphi/C++Builder!
Web : http://www.microtec.fr/copycat/cc

[spam}@westonmuir.com Steve Weston]

I've never worked with IB 5.0, so I can't hold any opinion about continuing
to use it. But, if you're going to support obsolete versions of software
because your customer base is too "poor" to pay for upgrades, then your
company ultimately shoulders the additional costs. Wit the release of IB
2007, you'll be supporting four major versions of IB and, as you say, be
limited to the capabilities of the oldest version. What are the current and
future costs of that choice? They may be insignificant in your situation,
but no so in ours.

It's an executive decision to support software that is no longer supported
by a vendor (Win98). I'm the executive here and I decided that we don't do
that. The bottom line impact on sales is zip, nada. The impact on support
costs is to our benefit.

--
Best regards,
Steven S. Weston

[Jonathan Neve[Microtec]]

Steve Weston wrote:

> I've never worked with IB 5.0, so I can't hold any opinion about
> continuing to use it. But, if you're going to support obsolete
> versions of software because your customer base is too "poor" to pay
> for upgrades, then your company ultimately shoulders the additional
> costs.

Sure, but in our case it's not that they're too poor, but simply that
we didn't see any convincing reason to upgrade, neither could we find
anything that would convince our customer. They would unhesitantly
upgrade if they had any reason to think it would be worth the cost
(that is, primarly, the cost of getting us to port our application to
the new version of the DB). And in fact, we have upgraded a few of them
in order to gain in performance. But for several, we are still using IB
5.

I think the reason is simply that we're doing custom development, which
means that each application we make is, with very few exceptions,
tailored to just one customer. In most cases, we also maintain their
machines, and, whenever there's more than 1 or 2 machines involved, we
setup a dedicated Linux database server. So the decision to upgrade or
not rests entirely in our hands, except of course that it will entail a
bit of development cost which our customer has to agree to. Hence, we
only consider upgrading for applications that we frequently make
changes to, or if there is a specific need (such as, performance) to be
addressed by the upgrade.

> Wit the release of IB 2007, you'll be supporting four major
> versions of IB and, as you say, be limited to the capabilities of the
> oldest version. What are the current and future costs of that choice?
> They may be insignificant in your situation, but no so in ours.
>
> It's an executive decision to support software that is no longer
> supported by a vendor (Win98). I'm the executive here and I decided
> that we don't do that. The bottom line impact on sales is zip, nada.
> The impact on support costs is to our benefit.

Yes, I guess our situations are probably very different. We still have
a number of customer with Windows 98, and we have no real support
problems. There's been the odd issue, but nothing much. Our software
has never had any problem running on Windows 98 (we did have a case of
Windows ME however, and we ended up reformating the machines and
installing Windows 98).

[jorge novoa]

"Bill Todd" <n...@no.com> wrote:
>You were almost certainly running with forced writes off which is an
>invitation to corruption in an environment where the machine running IB
>can crash. Your experience is not typical if IB is configured properly

I never see the forced writes, probably that could be the reason, but in a stand alone app. who db corrupts each two months, its too much, and i know probaly could be the computer hardware.

Another reason of db corruption could be the way of programming transactions(in delphi). For example for all the reading queries i set transaction to read commited and for all writing queries set another transaction to write consistency.

Regards

[jorge novoa]

"Steve Weston" <sweston{no spam}@westonmuir.com> wrote:
>Jorge,
>
>There are several things for you to consider when running an SQL database --
>IB or whatever:
>
>1) Run the current (or near current release) of the database. IB 6.0 is
>pretty old. It had several updates. IB 7 also has had several updates. So,
>there's no excuse for running IB 6.0 today.

why not?, i can`t tell to the client to purchase another licence just cause its better, the client doesn`t see that.

>2) Win98 is not a server OS -- never was intended to be. It was replaced
>many years ago by Win XP. Win98 is no longer supported by Microsoft. Why
>should you still support it?

Firstly, because win xp its one of the worst os i know, second win98 is less vulnerable to get virus, third why do i have to change the os if win98 its enough for the office work, four. its just a stand alone app. its not a network db app. why the client must invest into a os with server technology. And finally i`m in Mexico the people behavior and the interest of using sw its very different than usa or europe people.

>3) Any database will corrupt unless you take prudent precautions. Use hard
>writes. Use a UPS. Use a modern OS designed to be a server OS. Make backups.

You`re completely wrong, i have Ms win 2000 server runing oracle, and the ups was very old(we have a new one now) and when the electricty went out the server turned off, but the db never corrupted, and there was like 150 users connected to the server and db.

>Test your backups. Use the database maintenance functions to scan for
>problems.

I can`t be over my clients, they know the app. have backup options, but they never backup their db, i don`t know why.

Test your storage devices periodically. Don't let non-InterBase
>software touch your database (like generic backup apps).
>

how can you do that if your client do not obey to your indications(principally the way they are using the internet).

>We have clients across the USA that have been running our apps using
>InterBase for years. So far there has been only one case of database
>corruption -- and that was caused by a failing hard disk. We continue to
>recommend InterBase without reservation as extremely reliable for large and
>small installations (and we have some huge installations with very heavy
>workloads).

probably im doing something wrong(ib configuration, app. programming, etc. i don`t know).
regards

[Bill Todd]

jorge novoa wrote:

> I never see the forced writes, probably that could be the reason, but
> in a stand alone app. who db corrupts each two months, its too much,
> and i know probaly could be the computer hardware.

Running with forced writes off when IB is running on the user's
computer is very very likely to cause corruption anytime Windows
crashes for any reason. You cannot blame IB for the fact that you are
not using it properly.

>
> Another reason of db corruption could be the way of programming
> transactions(in delphi). For example for all the reading queries i
> set transaction to read commited and for all writing queries set
> another transaction to write consistency.

There is nothing you can do with transactions that will corrupt the
database.

--
Bill Todd (TeamB)

[Thomas Steinmaurer]

Bill,

>> I never see the forced writes, probably that could be the reason, but
>> in a stand alone app. who db corrupts each two months, its too much,
>> and i know probaly could be the computer hardware.
>
> Running with forced writes off when IB is running on the user's
> computer is very very likely to cause corruption anytime Windows
> crashes for any reason. You cannot blame IB for the fact that you are
> not using it properly.

I fully agree with that, but AFAIK InterBase 6.0 created databases with
forced writes = off by default, so a novice InterBase 6.0 user didn't
even know that he might get into trouble, cause of this odd behaviour.

Just my 2c.

--
Best Regards,
Thomas Steinmaurer
LogManager Series - Logging/Auditing Suites supporting
InterBase, Firebird, Advantage Database, MS SQL Server and
NexusDB V2
Upscene Productions
http://www.upscene.com

[spam}@westonmuir.com Steve Weston]

Jorge,

You have an unfortunate situation if your clients don't care enough about
their data to even make backups. It's really unfair of them to blame you for
problems they create. And there is really no reason to blame the problems on
InterBase in that case.

Yes, I understand the differences in user psychology and culture. Convincing
clients to spend money on hardware and software upgrades is sometimes
difficult, even in the USA.

I really have to disagree about using Win98 on stand-alone or workstation
PCs. Win98 has some serious memory management problems. It can also scramble
hard disk storage. Both problems can corrupt any database.

I can't see how an app can corrupt a database. An app can certainly bring
the database to its knees though if it mishandles transactions. Maybe the
most important IB configuration setting is to be sure forced writes is
turned on.

Where are you located in Mexico? What kind of apps do you develop? (My
previous post in this thread has our website URL, so one email address is
domainname at domainname dot com if you'd like to reply off-topic.) I'm in
So. California -- the Palm Springs area right now.

--
Regards,
Steven S. Weston

[Bill Todd]

Thomas Steinmaurer wrote:

> I fully agree with that, but AFAIK InterBase 6.0 created databases
> with forced writes = off by default, so a novice InterBase 6.0
> user didn't even know that he might get into trouble, cause of this
> odd behaviour.

I agree. Forced writes on should be the default. The situation is a bit
more complex with IB2007 where journaling is a better choice than
forced writes.

--
Bill Todd (TeamB)

[Craig Stuntz [TeamB]]

Bill Todd wrote:

> I agree. Forced writes on should be the default. The situation is a
> bit more complex with IB2007 where journaling is a better choice than
> forced writes.

But journaling has to be configured -- you really want your journals
going to a different drive, for the most part -- so it can't be turned
on automatically. What needs to happen is a GUI which could get
everything set up for you. I.e., turning on journalling would help you
set up the folder and suggest turning off forced writes.

--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
All the great TeamB service you've come to expect plus (New!)
Irish Tin Whistle tips: http://learningtowhistle.blogspot.com

[Bill Todd]

Craig Stuntz [TeamB] wrote:

> What needs to happen is a GUI which could get
> everything set up for you. I.e., turning on journalling would help you
> set up the folder and suggest turning off forced writes.

Exactly.

--
Bill Todd (TeamB)

[jorge novoa]

"Steve Weston" <sweston{no spam}@westonmuir.com> wrote:

>Jorge,
>
>You have an unfortunate situation if your clients don't care enough about
>their data to even make backups. It's really unfair of them to blame you for
>problems they create.

They thought the db apps. are magic, and behind the scenes i have to improve the app. trying to avoid user errors(but that never cause a db corruption before).

And there is really no reason to blame the problems on
>InterBase in that case.

I blame interbase because a electricity crash its not client fault.

>I really have to disagree about using Win98 on stand-alone or workstation
>PCs. Win98 has some serious memory management problems. It can also scramble
>hard disk storage. Both problems can corrupt any database.

I know, and i thought the hw machine or win98 os, causes corruptions for a client ofter, but Sorry again,i never heard about a oracle db corruption using win98.

>I can't see how an app can corrupt a database. An app can certainly bring

i never said that, i just ask if some wrong programming causes a db corruption.

>Where are you located in Mexico? What kind of apps do you develop? (My
>previous post in this thread has our website URL, so one email address is
>domainname at domainname dot com if you'd like to reply off-topic.) I'm in
>So. California -- the Palm Springs area right now.

Sorry, why are asking that(mexico location).
I develop middleware apps. for small and meduim bussines, but all this questions are cause i probablly going to develop a bigger db app(wan).

[jorge novoa]

Thomas Steinmaurer <t.steinmaurer_d...@upscene.com> wrote:
>Bill,
>
>>> I never see the forced writes, probably that could be the reason, but
>>> in a stand alone app. who db corrupts each two months, its too much,
>>> and i know probaly could be the computer hardware.
>>
>> Running with forced writes off when IB is running on the user's
>> computer is very very likely to cause corruption anytime Windows
>> crashes for any reason. You cannot blame IB for the fact that you are
>> not using it properly.
>
>I fully agree with that, but AFAIK InterBase 6.0 created databases with
> forced writes = off by default, so a novice InterBase 6.0 user didn't
>even know that he might get into trouble, cause of this odd behaviour.

You`re right i never notice foreced writes was off. But that is why im asking to learn

[jorge novoa]

oh, its good to know that, because i will test ib2007 and set it the journaling better than forced writes
>--
>Bill Todd (TeamB)

[spam}@westonmuir.com Steve Weston]

Jorge,

> I blame interbase because a electricity crash its not client fault.

InterBase is extremely tolerant of power failures. But only if forced writes
is turned on. If forced writes is on, then committed transactions will in
most cases be written to the HD. Incomplete transactions will be rolled back
when power is restored. That's an incomplete description of how it works.
See the docs, faqs and TIs for more information.

Also, if the client's data is important to them, they should have a UPS.
Power failures are a fact of life here in the USA (lightning strikes, wind
storms, and grid failures). A UPS will usually cover situations where part
of a committed transaction is written when the power fails.

> i never heard about a oracle db corruption using win98.

Oracle 10g requires: "Windows 2000 with service pack 1 or higher or Windows
Server 2003".

> Sorry, why are asking that(mexico location).

I asked only because as the North American economies become more integrated,
there are more opportunities for North Americans to work together. For
example, my company uses contract developers based in Canada. Canadian
developers sell apps in the USA. Many US companies focus on Spanish-speaking
markets. Developers based in Mexico have a market for their apps in the USA,
and vice versa. There are opportunities to work together.

--
Steven S. Weston

[jorge novoa]

">Also, if the client's data is important to them, they should have a UPS.

youre completly right, i always recomend it

>Power failures are a fact of life here in the USA (lightning strikes, wind
>storms, and grid failures). A UPS will usually cover situations where part
>of a committed transaction is written when the power fails.
>
>> i never heard about a oracle db corruption using win98.
>
>Oracle 10g requires: "Windows 2000 with service pack 1 or higher or Windows
>Server 2003".

i'm talking about priors versions

>> Sorry, why are asking that(mexico location).
>
>I asked only because as the North American economies become more integrated,
>there are more opportunities for North Americans to work together. For
>example, my company uses contract developers based in Canada. Canadian
>developers sell apps in the USA. Many US companies focus on Spanish-speaking
>markets. Developers based in Mexico have a market for their apps in the USA,
>and vice versa. There are opportunities to work together.

I appreciate your interest for chances of work together, i will be willing if there is any chance to do it. Just tell me what we have to do.
Regards

>Steven S. Weston
>
>