At 07:54 PM 1/07/2009, you wrote:

>> At 12:54 AM 1/07/2009, Henry Franquet wrote:
>> >Hi,
>> >I have a issue with a multicore laptop:
>> >OS Windows XP sp3, Firebird 1.5 classic server
>> >When the user software perform a restoration (using IBOService) which launch gbak to do the job, gbak returns in a instant without finishing the job.
>>
>> IBORestoreService doesn't use gbak, it uses the Services Manager.
>
>yes, it's what I thought before doing a log of the process launched: When restoring I saw a process named gbak ?

If you can eliminate the possibility that somebody is trying to run gbak.exe at the same time you are invoking a restore via the Services API, then I would recommend reviewing the code that your application runs when the user presses the "Restore" button.

Check everything. Database path names, user names, firebird.log....Note that, if your program is running on the host machine, you cannot use a "Windows local" (IPC) protocol for the connection to a database on Classic. In the service component, the database path syntax must be for Named Pipes (which IBO refers to as "NetBEUI") or TCP/IP (localhost, or the host server name). The backup file path should be the actual filesystem path to the file, NOT a network protocol path.

>> If you are talking about configuring CpuAffinity, it is not relevant for Classic.
>Yes, I knew it's why I tried to assign affinity to the program (with task manager) that use IBORestoreService without success.

The thinking here is wrong. The program that uses IBORestoreService does not run the restore. It only carries a request to the Services Manager (on the server) to run the restore.

>>Modify your settings in your IBORestoreService code (Verbose=True) so that you generate a log file into a visual component or a file. Then you will see why your restore fails. If you are already writing verbose output to a file, then check that a log file of the same name does not exist.

>I just loop while IsRunning then detach if Active.

Sorry, I have NO IDEA what you are talking about.

>The program runs for years without issue on monocore. I have made a new version to overcome the issue with multicore, but I can't migrate actually my customer and wonder how to do to recreate the condition of "monocore"
>
>Or may be I should use SuperServer (I have always use Classic on multicore) and set same affinity for Firebird and my program ?

Why? Should I repeat again, that clients cannot connect to (or create/restore) a database on a Classic server in Fb 1.5 using local protocol?

> Note also that, if you have (inadvisedly) set Replace true in the Options array then the restore will abort if any user is connected to the database. Of course, with the default CreateDatabase set true, the restore will abort if the database exists in the provided DatabasePath.
>Yes, I managed this too. It works well

If it works well, why are you telling us it doesn't work? ;-)

You still have not said what is written to your verbose output.

./heLen