[AccessD] RemoteEatBloat

Shamil Salakhetdinov shamil at smsconsulting.spb.ru
Fri Feb 19 06:34:53 CST 2010


Thank you, Max,

Honestly I thought you'd be interested to make the conversion by yourself :)
I'd still prefer you'll do that when Access.PowerTools will be ready to get
your plug-in hosted (v.0.0.3)
Why not?

<<<
I may also replace the Allform with your excellent code 
which loops through the Msys objects once I am happy 
with it all working  as-is.  That will be
an upgrade for me.
>>>
Max, that was bad idea of mine - looping through MSysObjects table doesn't
work from COM Add-In - no permissions runtime error message tells - I have
changed that code to loop using .Containers and .Documents collections - it
works in v.0.0.1 (that feature exists since Access 2.0 (1.1?)). BTW,
Access.PowerTools v.0.0.1 was tested with Access 2010RC and worked OK.

<<<
Please feel free to take all or any of the code and make use of it. 
I will send you a  copy off-line later today if that is ok with you.
>>>
Can we put that on Access.PowerTools site ready for download for everybody -
and maybe somebody else will come to convert it as Access.PowerTools'
EatBloat plug-in if not you or myself? :)

Thank you.

--
Shamil


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Wanadoo
Sent: Friday, February 19, 2010 11:20 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] RemoteEatBloat

Certainly Shamil,

No problems. I will be shortly  putting the finishing touches to it and you
can have a copy to play with.

There are two main differences between EatBloat and RemoteEatBloat:-

1. EatBloat
a. Allows individual selection of objects to export and import.
b. Sits inside another mdb as a self-contained form
c. Did not handle Relationships, References or linked tables.
d. All of the above may have changed in Dan's re-write to EatBloat2.

2. RemoteEatBloat
a. Is a standalone mdb which operates on an external mdb (hence Remote)
b. It works on complete collections of objects, ie AllForms, AllReports etc.
but DOES allow the user to say which collections to work on (or all of
them).  This way if there is a  problem with the external mdb, the user can
isolate which object is causing the problem, remove it  from  the source mdb
and then recreate  it on the newly created one manually at the end of the
job.
c. It does not cater for individual objects and thus works across the whole
external mdb in one go.
d. It handle Relationships, References and linked tables.
e. It exports ever thing to an intermediate mdb and from there using Compact
& Repair creates the destination mdb.
f. References can be text or GUID and will show which ones are broken etc.
g. Tables can be export in all ways or selected ways.  Clearly, only one way
can be imported otherwise  it will be creating additional table1, table2,
table3 etc which is not wanted.  
h. Linked tables (to BE) are NOT exported or imported.  The program does
create the links again however so that the new mdb has everything in place.

3. Currently RemoteEatBloat does not handle ActiveX or OCX or anything other
than native Access objects (at this time but who knows).

I think there is a place for both programs to meet differing needs.  I may
well extend RemoteEatbloat to handle individual objects in the future but
that will depend on whether or not I  personally have a need for it.  After
all, all of this originated by my own need to reduce bloat and because I
only dev in A2K3 that is the platform it is designed for.

Because it uses AllForm type collections it may well run on other Access
platforms as long as they support the undocumented features of SaveAsText
etc (although undocumented they have been around for years and work well).  

I may also replace the Allform with your excellent code which loops through
the Msys objects once I am happy with it all working  as-is.  That will be
an upgrade for me.

Please feel free to take all or any of the code and make use of it.  I will
send you a  copy off-line later today if that is ok with you.

Cheers

Max



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: 19 February 2010 06:43
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] RemoteEatBloat

Congrats, Max, William!

Max, if you wish we can convert your current EatBloat to an
Access.PowerTools plug-in - with all credits preserved and you having .NET
version to develop further and to publish new .NET EatBoat versions within
Access.PowerTools...

For us to not challenge each other :) 
I'd prefer cooperate not compete...
I like challenges but we have so many things to do that we'd better do
different things, and cooperate, than try to challenge each other on the
same field...
You can also make ActiveX .DLL from that plug-in, and use it without
Access.PowerTools etc.
I guess there soon will be no PCs without .NET Framework installed...

We can make conversion of EatBloat for Access.PowerTools v.0.0.4 - a plug-in
which will work exactly as your Remote EatBloat does - from current MS
Access instance will open another MS Access instance, and make it
"unbloated"...

Thank you.

--
Shamil

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of William Hindman
Sent: Friday, February 19, 2010 12:22 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] RemoteEatBloat

"It is an  Access  program and therefore if the source file has an access
problem then it is most unlikely that this program will overcome that." Max

...yes, but ...it makes it pretty easy to identify a problem file so you can

fix or remove it and run anew.
...can't say enough about how great a step up this is from what was already 
my favorite tool :)

...that said, Shamil and Dan's efforts are much broader in scope 
...especially Shamil's ...but
in my exclusively A2k3 world, this is the cat's meeeeooooooowwwwww!

...did I mention it was fast! ...'cause it is :)

...so is my client's "like new" application :)

William

--------------------------------------------------
From: "Max Wanadoo" <max.wanadoo at gmail.com>
Sent: Thursday, February 18, 2010 3:19 PM
To: "'Access Developers discussion and problem solving'" 
<accessd at databaseadvisors.com>
Subject: Re: [AccessD] RemoteEatBloat

> Ken,
>
> When I  wrote EatBloat and again for RemoteEatBloat I specifically stated 
> it
> was for A2k3 and it tests for this and  puts your current version on the
> title bar Eatbloat)
>
> I  don't know if Dan has made it less specific on the rewrite, but it may
> well be that he didn't and you may be having compatibility problems.
>
> Would you like me to send you on RemoteEatBloat to test? It is not yet
> finished and I have to handle Relationships and linking.
>
> So far it (RemoteEatBloat) handles For Export:-
>
> Tables (Local only - specifically does NOT do linked tables otherwise
> Imports to new mdb would be incorrect).
> Queries
> Forms
> Reports
> Macros
> Modules
> References
> Relationships (wip)
> Links (wip)
> It does not handle Pages (DAP) and I have no intention of bothering with
> that.
>
> It is a standalone unlike the Eatboat which required to sit inside the
> source mdb.
> It prompts for a source mdb
> Exports selected objects as listed above (tables can be csv, xls, xml or 
> all
> of them)
>
> For imports:
> It prompts for a new mdb.
> Imports exported objects into the new mdb.
> Compacts and Repairs
> Deletes the working  file.
> Again, the Relationships (wip) and Links (wip) are work in progress.
>
> The  source mdb  is not changed in any way.
> It is an  Access  program and therefore if the source file has an access
> problem then it is most unlikely that this program will overcome that.
>
> Let me know if you want a copy
>
> Max
>
>
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Kenneth Ismert
> Sent: 18 February 2010 18:08
> To: accessd at databaseadvisors.com
> Subject: [AccessD] RemoteEatBloat
>
> Max,
>
> Where do i get RemoteEatBloat? Does it work for Access 2000? If so, I'm
> willing to look at it.
>
> But to reiterate, SaveAsText/LoadFromText worked properly for the problem
> form. The database was reduced in size similar to decompile/compact &
> repair.
>
> However, the bloating did not go away. Subsequent edits to the form caused
> rapid file size increases and a drastic slow down in save times.
>
> -Ken
>
>
> From: "Max Wanadoo" <max.wanadoo at gmail.com>
>> Subject: Re: [AccessD] AccessD Digest, Vol 84, Issue 23
>> Would you like to try RemoteEatBloat and stick it into its own newly
>> created
>> form and then see if that reduces it (auto compacts and repairs) so you
> can
>> see what size it is.
>>
>> If it is reduced, then you could manually import it back into your main
>>  mdb
>>
>> Max
>>
>>
>> -----Original Message-----
>> From: accessd-bounces at databaseadvisors.com
>> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Kenneth Ismert
>> Sent: 16 February 2010 17:44
>> To: accessd at databaseadvisors.com
>> Subject: Re: [AccessD] AccessD Digest, Vol 84, Issue 23
>>
>> >
>> > Max (MGA):
>> > I have a similar problem but it is because  of a corrupt  form.
>>  Therefore
>> > RemoteEATbloat bombs out.  If I remove the offending form, it will
>> compact
>> > ok.
>> > So, my question is, with your problem mdb is the problem the form or
>> > EatBloat? Trying to pin down what else I can do to improve it.
>> >
>>
>> Now I see what you're driving at.
>>
>> The form is not corrupt in the sense that it doesn't work, or can't be
>> loaded. It functions fine. It is huge.
>>
>> And, EatBloat (SaveAsText/LoadFromText) works fine on the problem form --
>> no
>> errors, and the form is OK. It just doesn't fix the bloat problem. Edit
> the
>> problem form 2 or 3 times after EatBloat, and the database quadruples in
>> size. This is even for trivial changes, like moving a control, or
> modifying
>> a single line in code.
>>
>> The only conclusion I can reach is that, on A2K, there are certain bloat
>> problems that SaveAsText/LoadFromText can't fix.
>>
>> -Ken
>> --
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/accessd
>> Website: http://www.databaseadvisors.com
>>
>>
>>
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>



> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4878 (20100218) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru



-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4878 (20100218) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru






More information about the AccessD mailing list