When reverse engineering my database I am getting "Out of Memory" error after a few minutes when writing the script to a text file with data. I noticed no output file was ever created, so I am guessing EDBMgr was loading all of the script and data in memory before it would write it to disk. Just prior to getting the "Out of Memory" error, EDBMgr had consumed 1.96GB of memory according to the Windows resource mgr.

I'm wondering if a 64 bit EDBMgr would be better because I'm running Win7 64bit with plenty of memory?
Is there such a thing as a 64bit EDBMgr? Or should I compile my own?

TIA
Barry

I forgot to mention I'm using EDBMgr 2.13 B2 Unicode.

In the mean time, I will try EDBMgr 2.16 after backing up my database to see if that works.

Barry

On 4/22/2014 4:39 PM, Barry wrote:
> I'm wondering if a 64 bit EDBMgr would be better because I'm running Win7 64bit with plenty of memory?
> Is there such a thing as a 64bit EDBMgr? Or should I compile my own?

AFAIK there is no shipping 64bit version of EDBMgr. You could try to
compile it but have not tried myself - main problems might be the few
custom components and whether they have been separated into design and
runtime properly for 64bit compile.

Raul

Barry


I seem to recall from previous posts that your assumption is correct. The entire sql needed is first created in memory.

I don't have a table big enough to test with (I may create one later just to see) but as a workround what about reverse engineering without data, EXPORT the data from your table(s) and then use IMPORT to populate.

Roy Lambert

>I seem to recall from previous posts that your assumption is correct. The entire sql needed is first created in memory.<

Which is find for small to medium size databases. But grossly underpowered for larger database. It should write it out to disk when it can.

I looked into compiling EDBMgr for 64 bit but 64bit output is disabled.

>I don't have a table big enough to test with (I may create one later just to see) but as a workround what about reverse engineering without data, EXPORT the data from your table(s) and then use IMPORT to populate.
<

Well, that makes sense. But it creates a few more problems. I have to import the tables in the correct order to satisfy foreign key constraints. If that wasn't enough of a monkey wrench, EDB won't let me import Computed (or Generated?) columns. That means I have to export individual columns for each table so I can exclude the computed and generated columns. There is around 70 tables so I could be here for quite a while unless I create a script to do it.

Arrgghhhh.

Barry

On 4/24/2014 5:46 PM, Barry wrote:
> I looked into compiling EDBMgr for 64 bit but 64bit output is disabled.

What output is disabled  ?

I just tried and EDBManager compiles just fine into 64bit. this is on
XE5. Tried some quick operations including reverse-engineer of a small
DB and it worked ok

Raul

Hi Barry

<Barry> wrote in message
news:4D1ECD0B-B726-4B10-914A-90F60D93B950@news.elevatesoft.com...
>
<snip>
>
> Well, that makes sense. But it creates a few more problems. I have to
> import the tables in the correct order to satisfy foreign key constraints.
> If that wasn't enough of a monkey wrench, EDB won't let me import Computed
> (or Generated?) columns. That means I have to export individual columns
> for each table so I can exclude the computed and generated columns. There
> is around 70 tables so I could be here for quite a while unless I create a
> script to do it.
>
If you do have to resort to a script then there is Delphi code posted on one
of the newsgroups that creates a script to create a table from any dataset.
You could easily (?) change this to export the table, dropping columns
depending on being generate/computed.

I'll post my version of the code below, but best find the original in case I
have messed it up in some way that doesn't affect me

Cheers

Jeff
--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz

function GetCreateTableStatement(DataSet: TEDBDataSet;
 const TableName: String;
 TemporaryTable: Boolean = True): String;
var
 TempTableName: String;
 TempSQL: TStrings;
 i: Integer;
 TempFieldName: String;
 TempFieldSQL: String;
begin
 TempSQL := TStringList.Create;
 try
   TempTableName := CheckIdentifier(TableName);
   with DataSet do
   begin
     Open;
     FieldDefs.Update;
     if TemporaryTable then
       TempSQL.Add('CREATE TEMPORARY TABLE "' + TempTableName + '"')
     else
       TempSQL.Add('CREATE TABLE "' + TempTableName + '"');
     TempSQL.Add('(');
     for i := 0 to FieldDefs.Count - 1 do
     begin
       TempFieldName := CheckIdentifier(FieldDefs[i].Name);
       TempFieldSQL := '"' + TempFieldName + '"' + ' ' +
         UpperCaseString(FieldTypeToSQL(FieldDefs[i].DataType,
         FieldDefs[i].Size));
{$IFDEF D10ORHIGHER}
       if (FieldDefs[i].DataType in [ftWideString, ftFixedWideChar,
         ftWideString, ftFixedChar, ftGUID, ftWideMemo,
         ftMemo]) then
{$ELSE}
       if (FieldDefs[i].DataType in
         [ftWideString, ftWideString, ftFixedChar, ftGUID,
         ftMemo]) then
{$ENDIF}
         TempFieldSQL := TempFieldSQL + ' COLLATE '
           + GetCollationForField(FieldDefs[i].Name);
       if (i < (FieldDefs.Count - 1)) then
         TempFieldSQL := TempFieldSQL + ',';
       TempSQL.Add(TempFieldSQL);
     end;
     TempSQL.Add(')');
     Result := TempSQL.Text;
   end;
 finally
   FreeAndNil(TempSQL);
 end;
end;

Barry

>>I seem to recall from previous posts that your assumption is correct. The entire sql needed is first created in memory.<
>
>Which is find for small to medium size databases. But grossly underpowered for larger database. It should write it out to disk when it can.
>
>I looked into compiling EDBMgr for 64 bit but 64bit output is disabled.
>
>>I don't have a table big enough to test with (I may create one later just to see) but as a workround what about reverse engineering without data, EXPORT the data from your table(s) and then use IMPORT to populate.
><
>
>Well, that makes sense. But it creates a few more problems. I have to import the tables in the correct order to satisfy foreign key constraints. If that wasn't enough of a monkey wrench, EDB won't let me import Computed (or Generated?) columns. That means I have to export individual columns for each table so I can exclude the computed and generated columns. There is around 70 tables so I could be here for quite a while unless I create a script to do it.

I don't have a problem with computed fields (OK I only have one of them in my DB) or any of the generated fields and most primary keys are autoincs. I don't have any database enforced RI so I can't comment on that.

One thing I forgot to mention was that I found I needed to disable the triggers and reenable them at the end. Since my EXPORT / IMPORT routine is built in and user accessible for selection of tables its in Delphi but you should be able to extract the bits of SQL you need. What I don't know is if this also applies to database enforced RI. If not you still have to arrange the sequence yourself.

If you want me to have a play and come up with something that works please email me a SUBSET of your database with all the triggers RI etc but not so much data.

Roy Lambert

procedure UnsetTriggers(const DBase: TEDBDatabase; const TableName: string; Selector: string = '');
var
TriggerList: TEDBQuery;
begin
TriggerList := MakeEDBQuery(DBase);
TriggerList.SQL.Text := 'SELECT Name FROM Information.Triggers WHERE TableName = ' + QuotedStr(TableName);
if Selector <> '' then TriggerList.SQL.Add(' AND ' + Selector);
TriggerList.ExecSQL;
while not TriggerList.Eof do begin
 DBase.Execute('DISABLE TRIGGER "' + TriggerList.FieldByName(F_Name).AsString + '" ON "' + TableName + '"');
 TriggerList.Next;
end;
TriggerList.Free;
end;

procedure ResetTriggers(const DBase: TEDBDatabase; const TableName: string);
var
TriggerList: TEDBQuery;
begin
TriggerList := MakeEDBQuery(DBase);
TriggerList.SQL.Text := 'SELECT Name FROM Information.Triggers WHERE TableName = ' + QuotedStr(TableName);
TriggerList.ExecSQL;
while not TriggerList.Eof do begin
 DBase.Execute('ENABLE TRIGGER "' + TriggerList.FieldByName(F_Name).AsString + '" ON "' + TableName + '"');
 TriggerList.Next;
end;
TriggerList.Free;
end;

Roy

>I don't have a problem with computed fields (OK I only have one of them in my DB) or any of the generated fields and most primary keys are autoincs. I don't have any database enforced RI so I can't comment on that.
<

You lead a very sheltered life. <VBG>

>
One thing I forgot to mention was that I found I needed to disable the triggers and reenable them at the end. Since my EXPORT / IMPORT routine is built in and user accessible for selection of tables its in Delphi but you should be able to extract the bits of SQL you need. What I don't know is if this also applies to database enforced RI. If not you still have to arrange the sequence yourself.<

Good point. I forgot about triggers. Thanks.

Barry

>
If you do have to resort to a script then there is Delphi code posted on one
of the newsgroups that creates a script to create a table from any dataset.
You could easily (?) change this to export the table, dropping columns
depending on being generate/computed.

I'll post my version of the code below, but best find the original in case I
have messed it up in some way that doesn't affect me
<

Thanks.

I don't know why the "Import Table" of EDBMgr doesn't just ignore calculated columns instead of throwing an exception. Because as it is, the "Export Table" and "Import Table" won't work together if there are calculated columns.

Barry