| Subject | Re: [firebird-support] Embedded .vs. Full Server |
|---|---|
| Author | Helen Borrie |
| Post date | 2011-01-24T23:40:58Z |
At 11:40 AM 25/01/2011, you wrote:
As a reality check, what name did you rename fbembed.dll to? Does your application know which dll to load?
Just as a matter of interest - did you take in the information that "compacting the database" is not something you need to do for Firebird databases? The Firebird server engine takes full care of disposing of the "garbage" created by updates and deletes. There are ways to stuff that up...but, if your application is properly looking after its transactions, the Firebird engine will eventually re-use space on data and index pages that have been cleared by garbage collection.
Also - taking a backup once a week is *good* - and it is highly recommended to restore from that backup into a database file name that is DIFFERENT to that of the real database, just to make sure things work. But you do not need to do a restore after every backup. In fact, a gbak -replace_database restore is not recommended *at all*. There is no road back from it if something goes pear-shaped.
Running the backup *itself* will clear out any garbage that is found, as it goes along.
./hb
>Hi all...Well - you have more than one problem. I guess the first thing you have to get straight is that the server VERSION in v.2.5 (whether it be a full server model or the one inside the dll for Embedded) is 2.5. When you back up and restore your v.2.1 (or lower) database under Server version 2.5, your restored database will have the ODS (on-disk structure) that a 2.5 server creates, viz., 11.2. A database created (or restored) under a v.2.1.x server has an ODS of 11.1. A v.2.1.x server cannot open a database that has ODS 11.2.
>
>Well I have to say, ooopppsss! In a previous post I said, "Since yesterday, when I do the above, I get an error saying that the DB can't be opened because it is in use. This is the FIRST TIME this has EVER happened with FB, and it was only after upgrading to 2.5."
>
>Well, here's mud on my face. I found out why it happened. I have the full version (2.1.3.18185) installed, and to test the embedded version (mainly for compacting the db), I put the embedded version on my application DEBUG folder. The app works fine. Then the problem happens after I compact the database, using the local (DEBUG FOLDER) copy of the server (EMBEDDED) - it's coded to force the use of the EMBEDDED server at this point... I mean the run command used "..\gbak.exe (rest of the command string)", which forces it to use the GBAK.EXE in the DEBUG FOLDER (and when installed on the user's computer, the one in he APP folder). Here is my problem.
>Is there anyway, to force my program to use the embedded server, like through one of the configuration files, and not the installed server?ONLY have the fbembed.dll in the application directory. Nowhere else! And if there is a risk that your application is going to try to load a client located somewhere else (and thus try to attach to the wrong server) then fix up your application so that it will NOT find a Firebird client somewhere else!
>The reason I ask this, is there is a chance that a user might have FB full installed, which might be a different version, and I don't want things to mess up on their comupter.Exactly right. Don't ignore the recommended folder structure for your embedded application - as you are discovering, there are REASONS for it.
>I noticed that if I use FB2.5 on a DB, then try to access the same database with 2.1.3.18185... version 2.1.3.18185 tells me that the on disk structure is different and can't access it.Correct.
>So, I hope now that I've wiped the mud off my face, one of you kind folks can help me, and tell me how to force the use of the embedded server over the installed server.Hmmm - we still don't know what you're doing here that actually *allowed* your application to use the wrong client library and attempt to attach the database to the wrong server. fbembed.dll (renamed to fbclient.dll or even to gd32.dll) MUST be in the folder that the application regards as the "current directory". If it doesn't find it there, it will resort to looking up the PATH variable...which is probably what is happening here.
As a reality check, what name did you rename fbembed.dll to? Does your application know which dll to load?
Just as a matter of interest - did you take in the information that "compacting the database" is not something you need to do for Firebird databases? The Firebird server engine takes full care of disposing of the "garbage" created by updates and deletes. There are ways to stuff that up...but, if your application is properly looking after its transactions, the Firebird engine will eventually re-use space on data and index pages that have been cleared by garbage collection.
Also - taking a backup once a week is *good* - and it is highly recommended to restore from that backup into a database file name that is DIFFERENT to that of the real database, just to make sure things work. But you do not need to do a restore after every backup. In fact, a gbak -replace_database restore is not recommended *at all*. There is no road back from it if something goes pear-shaped.
Running the backup *itself* will clear out any garbage that is found, as it goes along.
./hb