Raul wrote:

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  ?
My mistake.

>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<

I tried compiling EDBMgr 2.13 B2 using XE2 32 bit and it compiles fine with a few deprecated styles warnings.
But EDBMgr AV's several times when it starts up, before window appears. I didn't bother with 64bit until I get the 32bit version working.

Would you mind compiling EDBMgr 2.13 B2 into 64 bit for me? And post a download link for it? (Compile it with XE5 if you like.) I want to see if I can reverse engineer my large database with it and get past the 2gb memory limit.

Thanks
Barry

Raul,

Oops. I forgot to mention I'm using the UNICODE version of EDBMgr 2.13 B2.

Barry

Barry


>>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>

No, on the contrary it was a conscious decision brought about by many occasions of being unable to sort out what should have been minor problems without resorting to backups thus losing work. Unless I was absolutely certain that other people's software outside of my control would be altering the database I would always enforce RI programmatically. Since these days its a hobby for me its easy. However, I had some major arguments in previous roles.

Roy Lambert

>No, on the contrary it was a conscious decision brought about by many occasions of being unable to sort out what should have been minor problems without resorting to backups thus losing work. Unless I was absolutely certain that other people's software outside of my control would be altering the database I would always enforce RI programmatically. Since these days its a hobby for me its easy. However, I had some major arguments in previous roles.<

That makes perfect sense in your case.

In my situation I decided to offload a lot of the intelligence into the database so it is more of a distributed approach and at the same time a learning experience for me. My client may want a web interface to the db at some point in time so offloading the Delphi code into the database will certainly help.

I was pleasantly surprised at how well EDB handles triggers, foreign keys, scripting etc, but understanding Intervals has a steep learning curve, as many people have discovered.  I think we were all spoiled by how effortlessly Delphi handled the arithmetic associated with date and time variables. Thankfully the people at Borland never created a committee to implement it.

Barry

Raul,

>Would you mind compiling EDBMgr 2.13 B2 into 64 bit for me? And post a download link for it? (Compile it with XE5 if you like.) I want to see if I can reverse engineer my large database with it and get past the 2gb memory limit.<

Disregard my last request (above). I discovered the "out of memory problem" when I reverse engineered the database was because I chose "Generate as Script" instead of "Generate as Generic Script".

"Generate as Script" will generate "Execute Immediate ..." statements in a script whereas "Generate as Generic Script" will just create the actual SQL statements inside of a script. The latter runs fine without creating any memory errors.

I don't even know why we need to have DDL commands executed using the "Execute Immediate" option. It would have to allocate a huge amount of memory for strings when loading tens of thousands of rows of data, as I have discovered.

The "Generate as Generic Script" works just fine.

Barry

Barry


Some generic comments to start with.:

Generate as generic script
This is suitable for running in EDBManager, but, unless I misremember, not in your own query. Each statement is terminated with ! and that means that EDBManager executes each statement individually in its own query. Its basically the same mechanism used by DBISAM. If you want to use this in your own code you would have to write your own string slicing stuff

Generate as script
You can simply cut'n'paste this into a script in your own code and, excepting memory issues, it will simply run

Generate as procedure
Pretty much as generate as script but for a procedure.

If you think about it in that way it makes sense to create the entire thing in memory since its going to have to go in there anyway.


<<I don't even know why we need to have DDL commands executed using the "Execute Immediate" option. It would have to allocate a huge amount of memory for strings when loading tens of thousands of rows of data, as I have discovered.>>

Going on what Tim has posted previously without that approach he would have been unable to provide dynamic binding (I think that's the prase he used) so scripts would be set in stone. Because EXECUTE IMMEDIATE doesn't care what's there and is just parsing and executing a string. This means that we can have code like EXECUTE IMMEDIATE 'CREATE TABLE '+ CAST(CURRENT_TIMESTAMP AS VARCHAR)'; and it will work.

However, my personal view is that unless you can guarantee that you will always have more free RAM than the database size PLUS any associated wrappers (eg EXECUTE IMMEDIATE and INSERT INTO etc) then you are doing it wrong. By eliminating EXECUTE IMMEDIATE you've come in under the wire this time but how many more rows do you need to add before you go over it again? You have to look at alternative strategies which do not involve holding the entire database in memory. I'm not sure wether IMPORT and EXPORT read and write on a row by row or entire file at once basis. I'll be interested if Tim can tell us. If its file at once I need to start thinking about what to do when the file size exceeds generally available free RAM.

As a bit of an aside I was going to suggest to Tim that he didn't export/import computed/generated columns but then I started to think about it and they are needed. The exported table could be imported into a spreadsheet, or a different table and that data could be needed.


Roy Lambert

Barry


>In my situation I decided to offload a lot of the intelligence into the database so it is more of a distributed approach and at the same time a learning experience for me. My client may want a web interface to the db at some point in time so offloading the Delphi code into the database will certainly help.

And now we can turn triggers off I may rethink things at some point

>I was pleasantly surprised at how well EDB handles triggers, foreign keys, scripting etc, but understanding Intervals has a steep learning curve, as many people have discovered. I think we were all spoiled by how effortlessly Delphi handled the arithmetic associated with date and time variables. Thankfully the people at Borland never created a committee to implement it.

They did, but at the end of the time allocated hadn't decided on tea vs coffee so nothing got done

Roy

Roy,

>As a bit of an aside I was going to suggest to Tim that he didn't export/import computed/generated columns but then I started to think about it and they are needed. The exported table could be imported into a spreadsheet, or a different table and that data could be needed.<

Well, just make "Export Computed or Generated Columns" as an option so you can have your cake and eat it too.

>>I was pleasantly surprised at how well EDB handles triggers, foreign keys, scripting etc, but understanding Intervals has a steep learning curve, as many people have discovered. I think we were all spoiled by how effortlessly Delphi handled the arithmetic associated with date and time variables. Thankfully the people at Borland never created a committee to implement it.<<

>They did, but at the end of the time allocated hadn't decided on tea vs coffee so nothing got done<
I know what you mean. Our last committee meeting on "Workplace Diplomacy" was stymied on whether to have cream, milk, sugar or lemon in our Earl Grey tea. A fist fight broke out and the Wedgwood all got smashed in the throwing melee so everyone went home bruised, battered, and missing a few teeth. The next meeting everyone agreed to order in soft drinks. No word yet on whether it will be diet or non-diet or cans or bottles. From what happened at our last meeting, I'm voting against buying bottled sodas.

Barry