I'd like to see a 64bit EDBMgr so I can load in large scripts that were generated from a reverse engineered database.
The 32bit EDBMgr will hang when I try and load in a large script, because of Delphi's 32bit Memo control.

I created a 64bit app for scripts and it loads and executes a 300k row script just fine.

Barry

On 7/2/2015 11:25 AM, Barry wrote:
> I'd like to see a 64bit EDBMgr so I can load in large scripts that were generated from a reverse engineered database.
> The 32bit EDBMgr will hang when I try and load in a large script, because of Delphi's 32bit Memo control.
>
> I created a 64bit app for scripts and it loads and executes a 300k row script just fine.

It's fairly easy to compile your own version of it for now

Raul

Raul wrote:

On 7/2/2015 11:25 AM, Barry wrote:
> I'd like to see a 64bit EDBMgr so I can load in large scripts that were generated from a reverse engineered database.
> The 32bit EDBMgr will hang when I try and load in a large script, because of Delphi's 32bit Memo control.
>
> I created a 64bit app for scripts and it loads and executes a 300k row script just fine.

>>It's fairly easy to compile your own version of it for now<<

Yes, but I did not have Delphi 64bit installed on my Win7 64bit machine at the time. Then I had to install EDB and its EDBComp components too.  It would be nice if Tim could compile EDBMgrx64.exe and have it on his site for download. It would save us a bit of work. It will also help the people who don't have a 64bit version of Delphi but still need to run large scripts from EDBMgr.

Barry

Progress update re:compiling EDBMgr to 64bit.

I got EDBMgr (v2.13B2 Unicode) compiled to 64bit and seems to work great.

Except it kicked the problem further down the road.
When I reverse engineering the database with data, I now get "Integer Overflow" instead of "Out of Memory" when it tries to export a 3500 row table (called Files) with CLOB data. The Clob data are CSV text files.

I can get around the problem by exporting the large Files table to a CSV file, then emptying the Files table before doing the export. I will have to do this for other large tables too. The whole reason for doing this is to export the data in one operation instead of a lot of manual labor.

Now I believe Tim fixed this Reverse Engineer problem in a later version of EDB.
But I am stuck with EDB v2.13 B2 (Unicode) for now.

I don't think this is possible, but I will ask this question anyways.

Can I use the current EDBMgr on a database with version 2.13B2 Unicode WITHOUT upgrading to table structure or database to the current version? I want to keep my code set at 2.13B2.

TIA
Barry

Barry


>Now I believe Tim fixed this Reverse Engineer problem in a later version of EDB.
>But I am stuck with EDB v2.13 B2 (Unicode) for now.

Remember the mantra "EDBManager is just an application"

It is unlikely (wild guess time) that the out of memory problem was an ElevateDB one but more liable to be caused by the components and controls within it. On that basis it should be possible to download the latest version, install in a VM, move the source to your system and recompile using the ElevateDB version of your choice. There may be new features that rely on a more modern version which will need to be commented out.

>I don't think this is possible, but I will ask this question anyways.
>
>Can I use the current EDBMgr on a database with version 2.13B2 Unicode WITHOUT upgrading to table structure or database to the current version? I want to keep my code set at 2.13B2.

Check the release notes, if there are no breaking changes, and no other changes that would impact you it should be safe.


Roy Lambert

Barry,

<< I'd like to see a 64bit EDBMgr so I can load in large scripts that were
generated from a reverse engineered database. The 32bit EDBMgr will hang
when I try and load in a large script, because of Delphi's 32bit Memo
control.  >>

I'll see what I can do.  Not a particularly difficult thing to add.

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com