> "Tim Young [Elevate Software]" wrote:

> << For the Server Explorer to work (without an open project) one needs to
> add it to the GAC. >>

> Are you sure about that ?  I use it with the Server Explorer with no
> problems without an open project, and I've got the data provider set up in
> the machine.config in the same way that our installation program installs
> it:
>
> Well, I'm quite sure on my system (Server 2008, VS2008), I have
> reinstalled several times (using vmware this takes minuttes)
> Without regestering it in the GAC I got the following error:
> "Could not load file or assembly 'elevate.elevatedb.data, version 1.9.3.0,
> Culture=neutral, PublicKeyToken=cf9bc1202c75e9e2' or one of its
> dependencies. The system can not find the file specified."
>
> I'll retest just to make sure.

I just did a retest and I'm getting the same error "Could not load file or
assembly......"
It doesn't help to add a Reference (with copy local) either.

As soon as I register the assembly in the GAC, everything is OK.

My machine.config file contains *almost* the same info as yours.
The difference is that mine has 1.9.3.0 and my path is ///C:\Program
Files\......

On top of that it is registered in the <DbProviderFactories> section.

This is using my standard setup.
Windows Server 2008 Enterprise, Visual Studio 2008 Professional.

--
Jan-Erik

Jan-Erik,

<< Is there a migrator included in ElevateDB? >>

I'm not sure what you mean ?  There are several migrators included with
ElevateDB - DBISAM, BDE, and ADO.

<< As for the time it took to convert, sure there was some time lost
converting to ANSI instead of Unicode.
(not all of the time was a waste, as I got aquainted with your programs and
the database script was quite a part of the process)  I'm used to click on a
few menues and the DBW takes care of the rest. (creating the scripts +
transferring the data) >>

So, did you use the migration facilities in ElevateDB to transfer the
initial data ?  What is the source of the data ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Jan,

<< I just did a retest and I'm getting the same error "Could not load file
or assembly......" >>

It sounds like a security issue, then.  However, the assembly is on the
local drive, right ?  That means that it should already be set up for "Full
Trust", by default.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]"  wrote

> << I just did a retest and I'm getting the same error "Could not load file
> or assembly......" >>
>
> It sounds like a security issue, then.  However, the assembly is on the
> local drive, right ?  That means that it should already be set up for
> "Full Trust", by default.
>

Yes, it's located on the local drive "C:\Program Files\...."

Notice: the last sentence in the error message I get in VS2008 is:
"The system cannot find the file specified."

I can't tell if it doesn't find it (there is nothing in the event log) but
the assembly is where it should be according to machine.config

Even if I reference the assembly in my project the exact same message pops
up if I try to configure a SqlDataSource.

So, in my case it has to be registered in the GAC.

--
Jan-Erik

"Tim Young [Elevate Software]" wrote
> Jan-Erik,
>
> << Is there a migrator included in ElevateDB? >>
>
> I'm not sure what you mean ?  There are several migrators included with
> ElevateDB - DBISAM, BDE, and ADO.
>
> << As for the time it took to convert, sure there was some time lost
> converting to ANSI instead of Unicode.
> (not all of the time was a waste, as I got aquainted with your programs
> and the database script was quite a part of the process)  I'm used to
> click on a few menues and the DBW takes care of the rest. (creating the
> scripts + transferring the data) >>
>
> So, did you use the migration facilities in ElevateDB to transfer the
> initial data ?  What is the source of the data ?
>

Tim,

I just read up on the MIGRATE statement and copied the ado dll to the server
directory.
It is now registered as a module, I'll check out how it works out later
today using MSSQL.
I could convert the data to MSSQL and then from MSSQL to ElevateDB if it
works out.

The database I transferred initially did not support any of the modules you
supply.
(it is an old project I'm refreshing/converting to ASP.NET from Delphi 7 /
dbExpress)

I created a script using DBW for the database and adjusted the file to
conform to ElevateDB.
The data was then imported using CSV files, as you know

I'm however concerned to what one can do from RAD Studio Win32.
My tests yesterday did not work out as I had hoped.
None of the Unicode fields are updatable (they are shown in the IDE) but as
soon as I run the application all strings are cut down to the first
character.
e.g.
 IDE                    Runtime
 MERCEDES -> M

When I tried to update a field (runtime) it ended up showing ???? ???? in
the EDB manager.

Is this what to expect without specific Unicode support in Delphi Win32?

Transferring jpg, pdf, gif, .... was no problem at all and this was the main
thing I wanted to accomplish.

PS!
I tried MIGRATE using the ADO module and it gave me the following error:
Error #202 ..... (An errorr occured with the module call OpenEDBModule(OS
Error: the operation completed successfully))

I'll do a another test using Windows Server 2003 in case Server 2008 is the
problem.

--
Jan-Erik

Jan-Erik,

<< Yes, it's located on the local drive "C:\Program Files\...."

Notice: the last sentence in the error message I get in VS2008 is: "The
system cannot find the file specified."

I can't tell if it doesn't find it (there is nothing in the event log) but
the assembly is where it should be according to machine.config >>

Are you using XP or Vista ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Jan-Erik,

<< The database I transferred initially did not support any of the modules
you supply.  (it is an old project I'm refreshing/converting to ASP.NET from
Delphi 7 / dbExpress) >>

If you can us dbExpress to get at the old data, you should be able to use
ADO to do so also.   Remember, ADO can use any ODBC driver to access just
about any data out there.

<< None of the Unicode fields are updatable (they are shown in the IDE) but
as soon as I run the application all strings are cut down to the first
character.
e.g.
 IDE                    Runtime
 MERCEDES -> M

When I tried to update a field (runtime) it ended up showing ???? ???? in
the EDB manager.

Is this what to expect without specific Unicode support in Delphi Win32? >>

Absolutely not.  Can you send me the database catalog (edbdatabase.edbcat)
and table (.edbtbl, .edbidx, and .edbblb) that you're using ?  Something is
definitely wrong, but I cannot replicate it here using the Unicode EDB
Manager.

<< I tried MIGRATE using the ADO module and it gave me the following error:
Error #202 ..... (An errorr occured with the module call OpenEDBModule(OS
Error: the operation completed successfully)) >>

Are you using the Unicode ADO migrator module (edbmigrateadounicode
directory), or the ANSI one ?  You need to use the Unicode migrator module
with Unicode apps.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote

<< Yes, it's located on the local drive "C:\Program Files\...."
>
> Notice: the last sentence in the error message I get in VS2008 is: "The
> system cannot find the file specified."
>
> I can't tell if it doesn't find it (there is nothing in the event log) but
> the assembly is where it should be according to machine.config >>
>
> Are you using XP or Vista ?
>

No

Windows Server 2008

Jan-Erik

"Tim Young [Elevate Software]" wrote
>
> If you can us dbExpress to get at the old data, you should be able to use
> ADO to do so also.   Remember, ADO can use any ODBC driver to access just
> about any data out there.

I'll investigate further if this is possible.


<< None of the Unicode fields are updatable (they are shown in the IDE) but
> as soon as I run the application all strings are cut down to the first
> character.
> e.g.
>  IDE                    Runtime
>  MERCEDES -> M
>
> When I tried to update a field (runtime) it ended up showing ???? ???? in
> the EDB manager.
>
> Is this what to expect without specific Unicode support in Delphi Win32?
>  >>
>
> Absolutely not.  Can you send me the database catalog (edbdatabase.edbcat)
> and table (.edbtbl, .edbidx, and .edbblb) that you're using ?  Something
> is definitely wrong, but I cannot replicate it here using the Unicode EDB
> Manager.

This is good news, I'll prepare something for you asap.
Did you receive the email I sent last night?


> << I tried MIGRATE using the ADO module and it gave me the following
> error: Error #202 ..... (An errorr occured with the module call
> OpenEDBModule(OS Error: the operation completed successfully)) >>
>
> Are you using the Unicode ADO migrator module (edbmigrateadounicode
> directory), or the ANSI one ?  You need to use the Unicode migrator module
> with Unicode apps.

Everything is Unicode (Server, Manager, and the dll from the unicode
directory).

Do I have to CREATE the MIGRATOR before I use it, the manual was a bit
unclear on this.

The command I used was (from within an active test database in the manager)

MIGRATE DATABASE FROM "ADO"
USING 'some_system_dsn_pointing_at_mssql_server'

--
Jan-Erik

Jan-Erik,

<< This is good news, I'll prepare something for you asap. Did you receive
the email I sent last night? >>

Yes, I did.

<< Do I have to CREATE the MIGRATOR before I use it, the manual was a bit
unclear on this. >>

Not for the EDB Manager - it will automatically create the migrator for you
if the DLL exists in the configuration path.

<< The command I used was (from within an active test database in the
manager) >>

Yes, that is correct.

I'm not sure what the issue is with the migrator on your end.  The Unicode
ADO migrator works fine here with the 1.09 B3 EDB Manager - I just tried it
here with an Access database and it works just fine.

--
Tim Young
Elevate Software
www.elevatesoft.com