I'm doing an Outlook Express Database (DBX) exporter and MDB importer.Time & Data are random, depending on each email data.I tested some emais with 3-4 MB attachments and take a couple of minutes... each one !I'm testing just now link the save imported mails procedure within the Load mails VBScript Function.It should be more efficient, because it don't need send data to NeoBook neither import data from Neo Variables.Perhaps vbScript should be the better solution...I guess next week i could send you a program for testing purposes.Grettings from Buenos Aires,David de Argentina

What about using a picture field instead? Despite the name, a picture field is actually a blob field and can be used to store any type of file. It might be faster since only the file's name is transferred between NeoBook and the plug-in. However, your data would have to be stored in a file.

If you're copying data from one table to another, you might be able to use SQL:

a) Extract any EML file from DBX Outlook Express Database (Inbox.dbx, sent.dbx, etc) and Store the created EML Files to an selected (Drive)Folderb) Batch import of all EML Files to store them into a selected table of a MDB Access Databasec) User can pick one (or several) EML Files and store them into a selected table of a MDB Access Databased) User can view the EML File, Extract Attachments, Print, etc.e) User can view the stored into MDB table, Extract Attachments, Print, etc.

DBX Files are like Frankenstein ones, not ADODB or ODBC compatible databases. No known programs can handle them.Is for this reason i can't use your suggestions...

This program could help Vista, Seven or 8 Windows users to keep access old emails stored on XP Machine...

I'm doing an Outlook Express Database (DBX) exporter and MDB importer.Time & Data are random, depending on each email data.I tested some emais with 3-4 MB attachments and take a couple of minutes... each one !David de Argentina

David, you are taking on a project I thought about but never jumped into.

I think Microsoft has many low level tools to access/search/sort data that we do not have so their searches are relatively quick. I suggest separating out the attachments from the from the .eml file (they are mime encoded), and storing them in a folder and only reference the attached files in the database by a title that would be a hash of the file or some other way to get around duplicate names.

This way, your searches are limited to smaller fields and the database size does not get uncontrollable. (I have Outlook PST files that are 4-5 gigs - they are similar to the files Outlook Express uses for storage).

Sounds like an interesting and challenging project. An email client does a lot of things.

I suggest separating out the attachments from the from the .eml file (they are mime encoded), and storing them in a folder and only reference the attached files in the database by a title that would be a hash of the file or some other way to get around duplicate names.

... is worth considering.

The file can be stored in folders that mirror the mailbox folder structures within Outlook Express plus 'the message record number' in the database ... and the actual file names would be file name of the attachment e.g. ...

Gaev wrote:The file can be stored in folders that mirror the mailbox folder structures within Outlook Express plus 'the message record number' in the database ... and the actual file names would be file name of the attachment e.g. ...

Just remember that some emails have multiple attachments and over time, you may have the same file name used again and again. So I might suggest creating a GUID for each attachment (see this thread on creating a GUID using a NB function - http://neosoftware.com/community/viewto ... 22&t=19563 ). Rename the file using the GUID. Then store in a folder. Have a table in the DB that associates the GUID with the original file name (and its location).

[Hmmm, may want to have a flat file with the same information in case the database gets whacked] - and create a restore process in case something happens to the db.

Use the GUID in the database to represent the file, then retrieve it as needed.

Actually program uses a specific folder ( c:\Mails ) in order to store the extracted EML filesThe attachments are stored into a C:\Mails\Temp FolderProgram is still under construction, when terminate, will allow user to select where the attachments will be put.

Just remember that some emails have multiple attachments and over time, you may have the same file name used again and again.

Not to go off on a tanget ... but the proposed naming scheme takes care of that ... e.g. you store the email in mailbox folder named John Doe ... which is a child of mailbox folder Customers ... which in turn is a child of mailbox folder NeoBook ... assume that the UNIQUE record number (in the Database) for this email message is 1234 ... then all attachments for this message would be placed in a (windows) folder c:\OE\NeoBook\Customers\John Doe\1234\ ... if this message had attachment files abc.jpg and xyz.jpg, you end up with ...

... the John Doe mailbox folder may later contain another message with an attachment called abc.jpg ... which may or may not have the same content as the earlier message ... assuming that this new message was stored in the Database with the record number of 4567 ... its attachment would be stored in ...

c:\OE\NeoBook\Customers\John Doe\4567\abc.jpg

... different messages with the same named attachment file should be placed in separate locations ... so I don't see the problem with multiple attachments.

@David de Argentina:

Program is still under construction, when terminate, will allow user to select where the attachments will be put.

... and hopefully to also select the folder for the EML files (c:\mail) ... and the name and folder for the database.

* Zip has 2 files: DBX2EML2MDB.exe is the the mail handlerMyMailViewer.exe is the mail viewer. First time you run, program try to set itself to the default launch program for .EML files. If not work at second try, you could set this program manually

* In theory, you could open any EML file from anywhere. I defined c:\Mails folder to export the Mails within DBX files. You can change this.

* Batch Import EML to MDB: At this time, i compiled the program with the dbpAddRecord / Setvar "[db.Table.field]" "blah" / dbpSaveEdits. This is not the best solution, but i don't get error messages.

* When you open a mail using the MyMailViewer program (or double click on DBX2EML2MDB.exe row) if you see into the attachment combobox something like "NoName.EML", is just a resend email that contains another EML within. You could open it clicking the "See Attachment" button.

Tell me if anything works fine for you.Greetings from Buenos Aires,David de Argentina