Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 5 of 5 total |
DBISam not true SQL? |
Mon, Aug 27 2007 6:29 AM | Permanent Link |
"Adam H." | 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. |
Mon, Aug 27 2007 11:11 AM | Permanent Link |
Bill Mullen | >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. |
Mon, Aug 27 2007 11:33 AM | Permanent Link |
"Robert Eastlack" | "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? |
Mon, Aug 27 2007 5:30 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Mon, Aug 27 2007 8:04 PM | Permanent Link |
"Adam H." | 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. |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |