Hi,

Forgive me - I might be a bit daft, but I'm left scratching my head from a
conversation I had the other day with a prospective clients IT manager.

They were looking at one of my applications, and the IT Manager wanted to
know what database it ran on, to which I replied DBISam.

They asked if it was a true SQL server - and I wasn't quite sure what they
were on about. I explained that it can be used in Local Access Mode, or via
a Client/Server based system - but I don't think they understood where I was
comming from.

To simplify it (and forgive me Tim for using this as an example , I said
that it could be configured either like an Access Database, where the
application accesses the table directly, or via a Client/Server based system
like MSSQL. <cringe>

I was then asked about backups, to which I replied how simple it was to back
up. From the conversation however, I think that he and I were on different
wavelengths.

He continued to talk about SQL as though there should have been a log /
transaction / record for every insert/delete/edit into the database (and I
think this was relating to his 'back up' question previous.) The
conversation ended shortly after where I said I logged certain events (such
as deletes to critical info, etc, but didn't go as far as every single event
within the system.

Later I heard from someone else in the company that he wasn't happy as it
wasn't a true SQL database, and that was the reason he didn't want this
company to use my product.

Now - with all this, I'm thinking that I'm ignorant about something, or have
missed something. (OK, admitidally, this company is a very large company and
I think they're a little concerned about security, etc - and if so, it might
be better for them to get someone to write a custom package to suit them
directly), but I've been left wondering if I've missed something that I
should know about.

In no way am I dissapointed (or think that I'm missing out on something) by
using DBISam. I'll drop new prospective clients before I drop DBISam (as my
current clients are wrapped with DBISam, as I constantly am too!).

However I don't want to sound as stupid as I did the other day if the
question's ever asked again - so I thought I'd ask the question and look
stupid amongst friends on this NG instead. Can anyone shed some light as
to what he may have actually been talking about. Am I missing something
here, or was this just a wierd conversation I should just forget about.

Cheers

Adam.

>I was then asked about backups, to which I replied how simple it was to back
>up. From the conversation however, I think that he and I were on different
>wavelengths.
>
>He continued to talk about SQL as though there should have been a log /
>transaction / record for every insert/delete/edit into the database (and I
>think this was relating to his 'back up' question previous.) The
>conversation ended shortly after where I said I logged certain events (such
>as deletes to critical info, etc, but didn't go as far as every single event
>within the system.
>

Adam,

MS SQL server, Oracle, and others have transaction logs. These logs
store changes to a database (e.g. inserts, deletes, updates, etc) and
can be used to roll forward transactions since the last database
backup.  In effect, allowing you to completely rebuild a database in
the event of a crash, with little to no data loss.  Granted, if the
hard drive crashes and the transaction logs are destroyed, you won't
be able to recover, but most transaction logs are stored on different
drives and in many cases, different computers.  

Basically, what happens is that when these systems perform a backup,
once the backup is complete, they purge/erase the transaction logs and
start logging from the backup point forward.  In a crash, you would
restore from your backup, then you would start executing the data
changes that are stored in the transaction log to bring the database
back to the point where the crash occured.  Some DBMS' allow you to
roll forward (recover) to a point in time which can be real handy too.

There are different configurations and options that allow the DBA to
set the level of backup and transaction.  

"Bill Mullen" <noprivateemail@domain.com> wrote in message
news:hpn5d3l8vc2odstj89lr27hpifctbsdbjo@4ax.com...
> >I was then asked about backups, to which I replied how simple it was to
> >back
>>up. From the conversation however, I think that he and I were on different
>>wavelengths.
>>
>>He continued to talk about SQL as though there should have been a log /
>>transaction / record for every insert/delete/edit into the database (and I
>>think this was relating to his 'back up' question previous.) The
>>conversation ended shortly after where I said I logged certain events
>>(such
>>as deletes to critical info, etc, but didn't go as far as every single
>>event
>>within the system.
>>
>
> Adam,
>
> MS SQL server, Oracle, and others have transaction logs. These logs
> store changes to a database (e.g. inserts, deletes, updates, etc) and
> can be used to roll forward transactions since the last database
> backup.  In effect, allowing you to completely rebuild a database in
> the event of a crash, with little to no data loss.  Granted, if the
> hard drive crashes and the transaction logs are destroyed, you won't
> be able to recover, but most transaction logs are stored on different
> drives and in many cases, different computers.
>
> Basically, what happens is that when these systems perform a backup,
> once the backup is complete, they purge/erase the transaction logs and
> start logging from the backup point forward.  In a crash, you would
> restore from your backup, then you would start executing the data
> changes that are stored in the transaction log to bring the database
> back to the point where the crash occured.  Some DBMS' allow you to
> roll forward (recover) to a point in time which can be real handy too.
>
> There are different configurations and options that allow the DBA to
> set the level of backup and transaction.

I wonder how hard it would be to implement this in DBISAM using triggers.
Has anybody tried?

Adam,

<< Later I heard from someone else in the company that he wasn't happy as it
wasn't a true SQL database, and that was the reason he didn't want this
company to use my product. >>

It is most definitely a true SQL database.   However, it does lack a few
major items that are found in most commercial SQL database servers, namely
automatic disaster recovery and RI.

Bill's description is a very good description of what online disaster
recovery is.  There are couple of different ways to perform online disaster
recovery, with logging being one of them.

--
Tim Young
Elevate Software
www.elevatesoft.com

Good Morning Bill and Tim,

Thank you for your descriptive reply. I think I understand a little more now
where he was comming from, and maybe "True SQL" was not the best phrase he
could have used to describe what he was after, but no harm done - I've got a
pretty good understanding now.

Thanks guys!

Adam.