Shamil Salakhetdinov
shamil at smsconsulting.spb.ru
Sun Feb 14 11:11:30 CST 2010
Hi Max et al,
I have made quite some C# coding to implement "EatBloat" (Export/Import)
using .NET.
Below you can find download link for the sources.
As you can find this is a set of projects, which are ready to be "plugged"
to a COM Add-In whatever way you will develop it using Add-In Express or
not. There is no any Add-In Express refs/sources there yet - so the
published stuff can be used freely.
Current status is that the export of Access db objects and data into
text/xml files, and import back/restore into a fresh MS Access db worked
well in Automation mode. Next step will be to use this coding with Add-In
Express to make Access version independent add-in.
Please ask any questions as this is a rather advanced stuff.
Please give me time to reply as I have to do other work for money in
parallel.
I'd prefer to keep this thread here as it's related to MS Access Add-In(s)
development using modern development tools to automate routine everyday MS
Access developers' work by developing different plug-ins.
As you can find the published sources were developed using mainly Test
Driven Development (TDD) approach - that allowed me to make that coding
relatively quick without any debugging sessions, and ready to be hosted in
an Access Add-in - agile practice in action...
I have got "christened" this tool as "Access.PowerTools.[Add-In]".
The stuff was developed using VS2008 SP1 on Vista Ultimate with MS Office
2007 (one project from the set is currently Access 2007 (12) dependent - it
uses Access Primary Interop Assembly v.12. There is also reference tp DAO
2.6 in the same project. The Add-In which will be developed further using
Add-In Express will not have these references/dependencies.)
Look http://northwind.codeplex.com/releases/view/26600
for Access.PowerTools.Code.100214.zip
http://northwind.codeplex.com/releases/view/26600#DownloadId=106137
Thank you.
--
Shamil
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Wanadoo
Sent: Sunday, February 14, 2010 1:32 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Add-In Express 2009 for MS Office and .NET - Create a
NEW DB and populate with objects.
Thanks Shamil,
I look forward to your development.
In your code, you missed the TARGET folder from this code:
app.ExportXML acTable, _
rst![ObjectName].Value, _
strTargetFileName + ".xml", _
strTargetFileName + "Schema.xml"
should it be:
app.ExportXML acTable, _
rst![ObjectName].Value, _
strTarget + strTargetFileName + ".xml", _
strTarget + strTargetFileName + "Schema.xml"
Max
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: 14 February 2010 09:33
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Add-In Express 2009 for MS Office and .NET - Create a
NEW DB and populate with objects.
Hi Max --
Thank you for your note.
In fact you can do that new db creation without intermediate usage of text
files - just use .TranferDatabase, e.g.
- having db to be "packed" opened within MS Access IDE close it, and create
new db then use .TransferDatabase to import all objects one by one using
.Containers and .Documents collections to select source objects, or a query
over MSysObjects...
The issue with that approach (and the one you propose below) is that in
general case in the new db you'll have also to recreate:
- references;
- database properties;
- user defined properties;
- relationships;
- ? something else I missed ?
So, I'd currently keep the "EatBloat" simple as it is:
- export all objects into text files;
- import all objects back from text files (handle tables' import as a
special case discussed earlier here);
- compact db;
This "lightweight" approach assumes that there is no relationships in the db
to be "packed" as well as this is a developer's/user's duty to make db
backup before running export/import to "eatbloat" (yes, it's easy to make
backup of db by code but then current db should be closed before making
backup, and when reopened within MS Access IDE it could run autoexec macro
or start-up form, yes we can temporarily block them but then we will be
changing source db anyway - let's not do that for now...)
As I noted in one of the posting in this thread, quite some time ago in 1999
I have been involved in a project called "Application Manager", which did
many "tricks" with "shuffling" MS Access objects between a set of databases,
setting references, (re)creating user defined properties, injecting
"plumbing code", packing all stuff as InstallShield/SageKey setups etc.etc.
All that can be done but it takes time ("Application Manager" took almost
three months fulltime) therefore let's (for now) follow KISS principle to
not "sink in the implementation details" - I suppose "lightweight" approach
should work rather well for most of the real life cases (as William noted),
there should be just one option added probably to make tables'
backup/restore option selectable before export/import - then "lightweight"
approach will also work with the databases with relationships.
The next step could be to make it working for db with relationships - and
there could be at least two ways to do that:
- 1. from a set of existing relationships get (a) data dropping and (b) data
importing sequence and use (a) to drop all tables' data after they are
exported into text files, and use (b) to import all data from the tables;
- 2. Save tables' data as text, save Relationships definition, drop all
relations, import data from text, recreate relations.
When that is working saving/recreation of references can be added etc...
Thank you.
--
Shamil
<<< snip >>>