About importing rather large .sql files

[expired user #2759]'s profile image [expired user #2759] posted 16 years ago in Import/Export Permalink
I've been thinking... since the current method has some memory leaks that make the operation to take a lot of time and other programs to misbehave (at least with latest versions)... why don't you try to port the php code from BigDump to Delphi? I think it would be a nice approach.
[expired user #1125]'s profile image [expired user #1125] posted 16 years ago Permalink
Sounds to me like a lot of work that would unnecessarily introduce additional "new code" bugs.

Feel free to submit a patch, then it can be tested whether your approach is better than the current one.

There should be no large memory leaks in version 3.2 (see revision 1117), the remaining ones should be string lists, of which I am unaware of any major usage during SQL exports.
[expired user #2759]'s profile image [expired user #2759] posted 16 years ago Permalink
Well, it's not my approach as I didn't make it hehe, also, I don't have nor know Delphi, and judging from what the php scripts it wouldn't be surprising if something similar is already made.

About the memory leaks, dunno, but trying to export big dumps (near 1gb, mainly ones that don't make use of the extended insert syntax) make most applications on my PC to show gfx glitches, and I have a E6850 with 3GB of RAM.

Anyway, this was just a suggestion that suddenly popped out of my mind while trying to import some databases at home, I'm not demanding anything, plus if I could chose what would be done next I'd go for those access violations when browsing tables, because I thought I didn't experience them, but recently saw I sometimes suffer them, mainly when trying to sort tables with a sh*tload of records by clicking on a column header, and once I get one of them I have to close the application or I get more errors sooner or later.

Please login to leave a reply, or register at first.