Hi all,

we can't start migration if the dbsrvr is running as service. Possible that the service can't open the migrationxx.dll files? If we stop the service, run the dbserver as application, the migration is ok.

Is this a known problem or I'm doing something wrong?

Yusuf Zorlu
MicrotronX

Yusuf,

It's probably the server not finding the dll.
Put the dll in the same folder where you have the configuration file and check again.

--
Fernando Dias
[Team Elevate]

Fernando Dias wrote:

Yusuf,

It's probably the server not finding the dll.
Put the dll in the same folder where you have the configuration file and check again.


Hi Fernando, we have the server and all dll's in same folder but not working. I think this is a limitation somewhere with services.

Yusuf Zorlu
MicrotronX

Yusuf Zorlu wrote:

Hi all,

we can't start migration if the dbsrvr is running as service. Possible that the service can't open the migrationxx.dll files? If we stop the service, run the dbserver as application, the migration is ok.

Is this a known problem or I'm doing something wrong?


I know exactly what the problem is, as we hit the same issue. If only I could remember what the solution is. I'll check it out and come back.

Right.

This is an OS permissions issue. The EDB server service runs in the local SYSTEM account on the machine. The local SYSTEM account does not have permissions to access the folder where the soure of the migration is. You need to add the local SYSTEM account of the server machine to the list of objects which can access the migration source, which may be on a different machine.

From what I wrote earlier:-

When migrating a system from version 4 to version 5, the migration of the v4 DBISAM database in performed by the DBISAM4 migrator module, which runs as part of the ElevateDB database service process. As installed, the EDB servers are Windows services, which are installed to run using the local machine’s (the server on which it is installed) SYSTEM account. The SYSTEM account of a machine has access to all resources of the machine. The SYSTEM account however, doesn’t have access to resources on other machines. If the version 4 DBISAM data lives in a share on a different machine to that which will be hosting Exportmaster 5’s databases, the migration process will fail to find any tables to migrate. It won’t fail, it just won’t migrate anything. There is now a test in the migrator program to check that tables exist after performing the migration. It will fail if nothing has been migrated.

There are two solutions (probably more) I have come up with so far:-

1.   Grant ‘Everyone’ all permissions in the version 4 share. This does leave the Share wide open, so should be revoked after migration.
2.   Grant the machine hosting the Exportmaster 5 databases all permissions in the version 4 share. Eg, if the EDB server for Exportmaster 5 is running on a machine called ‘WIN2008R2-TEST’, grant the necessary permissions on the version 4 share to a computer named ‘WIN2008R2-TEST$’.

Yusuf,

<< we can't start migration if the dbsrvr is running as service. Possible that the service can't open the migrationxx.dll files? If we stop the service, run the dbserver as application, the migration is ok. >>

Are you seeing an error message, either in the client application or in the logged events for the EDB Server ?

Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>> Are you seeing an error message, either in the client application or in the logged events for the EDB Server ?

Hi Tim, yes i see an error but don't remember. Will try today / tomorrow new migrations and will note the messages + post them here.

Yusuf Zorlu
MicrotronX

Solution was pretty simple:

We had the user SYSTEM with full access to the folder where all exe and dll files resists.
Adding the user SERVICE has solved the problem.

Yusuf Zorlu
MicrotronX