The Auto FE Updatrer will no longer be free

[a a r o n . k e m p f]

Tony;

You're full of shit, a pansy and a wuss.

Keeping all your views / sprics in SQL Server means that people don't
need to download 3rd party bullshit like yours

Trying to sell.. Access code. ROFL OMG

-Aaron

 

[a a r o n . k e m p f]

You're just some dumb **** eskimo retard that doesn't have the mental
capacity to learn a real database.

Anyone with a clue moved to SQL Server a long time ago.

-Aaron

 

[Tony Toews]

You're just some dumb f*** eskimo retard that doesn't have the mental
capacity to learn a real database.

Anyone with a clue moved to SQL Server a long time ago.

Your feedback will be treated with the respect it deserves.

Thank you for your comments.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[Access Developer]

Your feedback will be treated with the respect it deserves.

How can you do that, Tony? Electronic feedback is rather difficult to toss
on the manure heap.

Larry

 

[The Frog]

Its good to see that the group troll is still around - I do miss a
good laugh at its antics.

Selling the FE Updater is a great idea IMO. Licensing the thing could
prove difficult. Have you thought about a form of licensing where the
number of administered applications is the controlling factor? Tiered
levels, 1-5, 6-10 etc... Keep just one codebase and limit the scope it
can operate across.

Likewise you could consider a separate integrated update
administration for .XLS and other office add-ins under the same
structure. Managing the .XLS add-ins is a pain in most corporate
structures, even with tools like ZenWorks (massive overkill for such a
simple thing).

Just my 2 cents

The Frog

 

[David-W-Fenton]

"a a r o n . k e m p f @ g m a i l . c o m" <[email protected]>
wrote in
m:

you DO know that it would be a lot easier if everyone just kept
their tables / queries in ONE PLACE - on a database server where
they belong, right

Aaron, you should read posts before responding to them.

Tony's utility is an auto FRONT END updater, which has nothing
whatsoever to do with whether your data is stored in a Jet/ACE data
store, SQL Server, MySQL, PostgreSQL or whatever.

You really do make yourself look remarkably stupid when you post
crap like this.

 

[David-W-Fenton]

"a a r o n . k e m p f @ g m a i l . c o m" <[email protected]>
wrote in
m:

Anyone with a clue moved to SQL Server a long time ago.

You really are going for the MOST STUPID PERSON OF THE YEAR aware,
huh?

Distributing FRONT ENDS doesn't have anything to do with what BACK
END is used by that FRONT END. And anyone using SQL Server still has
to have a front end to the database.

Gad, but you are just dumber than a box of hammers.

Way dumber than a box of hammers -- at least one could use a box of
hammers for something.

 

[Tony Toews]

Selling the FE Updater is a great idea IMO. Licensing the thing could
prove difficult. Have you thought about a form of licensing where the
number of administered applications is the controlling factor? Tiered
levels, 1-5, 6-10 etc... Keep just one codebase and limit the scope it
can operate across.

Sure, that's a thought that hadn't occurred to me. I could also
license by the number of users. Right now I'm just keeping it simple
at the number of servers.

Likewise you could consider a separate integrated update
administration for .XLS and other office add-ins under the same
structure. Managing the .XLS add-ins is a pain in most corporate
structures, even with tools like ZenWorks (massive overkill for such a
simple thing).

??? Now this is a new concept to me. The concept that this is a
signifcant issue. That said I do have a blog entry on that exact
topic.
http://msmvps.com/blogs/access/arch...fe-updater-to-distribute-an-excel-add-in.aspx

What's so special about Excel AddIns? Or just that they are
pervasive in some organizations that use Excel a lot? What is the
target folder generally?

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[The Frog]

Hi Tony,

Excel add-ins are quite prevalent in larger corporations. They are
mostly used to either add functionality to Excel that it doesnt
already possess, attach Excel to BE databases for referential data
that they dont want to Pivot but use more like a VLookup, and of
course automating / templating analytical reports. One I am working on
right now (Super urgent - got to have it yesterday!) is a set of
wizards to simplify complex graphing procedures (MariMekko, Quadrant
Bubble, Heat Charts, etc...). The issue with Excel add-ins is that
there is no version control, same as there is for FE's. When you make
an update you have to rely on the user to swap out the file for
the .xla (before Excel is running).

In theory you could program a 'main' button on a toolbar to do file
checking before activating the real .xla, but there are serious
inconsistancies between versions of Excel in the way this is handled.
In my corporate environment we have a mix of 2000, XP (2002), 2003,
2007. If we include some of our business partners in the mix we range
from 97 to 2010. You cant cover every contingency with a single
'standard' approach in Excel, but you can cover most and my office
environment is running the add-ins fine. The only way I can guarantee
that the macro that is being used is kept up to date is to hand it to
our IS group to turn into an .MSI installer each time a change is
made. This is massive overkill, expensive (~€1000 per .msi), and takes
a long time to implement. In short, handling .xla files through the
Updater, combined with Access FE and BE files, and maybe even other
office add-ins (we have some for Powerpoint and Word too), template
files and so forth, IMO you would be on to a definite winner. It
wouldn't take much (it seems) to place some simple 'end user' type
management for these additional file types. I am thinking that a
complete non-technical person could theoretically managa things here
(or as close as possible - high school aint what it used to be).

An application like that, which allows people / offices to customise
their office setup and maintain some standards at the same time would
be a real boon. At the moment I am using some simple scripts for
managing the other add-ins, but it is not particularly elegant. An
integrated Updater would do the job nicely. In theory you can do it
now, its just not clean so to speak.

I hope this helps

The Frog

 

[The Frog]

When our resident troll graces us with its presence I manage to have a
good laugh with my coffee in the morning. Severe case of D.A.D.S. it
seems our troll suffers from. Still, I cant complain about breakfast
and a show!

The Frog

 

[Clif McIrvin]

Hi Tony,

Excel add-ins are quite prevalent in larger corporations.

-------

I'm quite a newcomer to add-ins so perhaps I'm way over-simplifying
here. I am using Tony's AutoFEUpdater to manage a VBA add-in at work.

Office 2010; Win XP
Target Folder: %appdata%\Microsoft\AddIns\

In my environment everyone is on the same Office version, so that is not
an issue for me. Essentially, I'm using AutoFEUpdater as a vehicle to
pull the updated add-in (.xlam in this case) to the user's local addins
folder. [I'm using the copy only option and the user setup email to
distribute updates.]

I am making an assumption that the user is not running Excel when (s)he
pulls down the updated add-in.

 

[Ron]

I bet even Aaron's mother can't stand him..............

 

[Tony Toews]

In short, handling .xla files through the
Updater, combined with Access FE and BE files, and maybe even other
office add-ins (we have some for Powerpoint and Word too), template
files and so forth, IMO you would be on to a definite winner. It
wouldn't take much (it seems) to place some simple 'end user' type
management for these additional file types. I am thinking that a
complete non-technical person could theoretically managa things here
(or as close as possible - high school aint what it used to be).

Several things have been implemented or will be implemented that could
help this concept.

1) The Start Method = Display File Count Message option
http://autofeupdater.com/pages/settings4.htm
handles the situation where the user only needs to update files.
That's not very well worded. "This option does not start an Access FE
database file or another file but just displays a message indicating
how many files were copied to the target PC"

2) I plan on adding a feature where the Auto FE Updater will,
optionally, startup when the user logs in and resides in the system
tray and every x minutes it will check to see if there are files to be
updated. If the user isn't in the file it will update it silently.
If the user is in the file it will blink telling the user there is a
new file. And maybe the Auto FE Updater residing on the developers
system will automatically send all active users an email indicating
there is an update.

3) A few other enhancements that I don't want to get into right now.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

 

[David-W-Fenton]

"a a r o n . k e m p f @ g m a i l . c o m" <[email protected]>
wrote in
:

You're full of shit, a pansy and a wuss.

So glad you continue to much such strenuous efforts to elevate the
level of discourse!

Keeping all your views / sprics in SQL Server means that people
don't need to download 3rd party bullshit like yours

The issue of distributing and uploading the front end to your
database application does not disappear just because you upsize the
back end to SQL Server.

Trying to sell.. Access code.

Free clue, Aaron: Tony's updater is not Access code.

But do keep up, posting something new every day that reveals yet
again the full depths of your ignorance and stupidity.

We all find it quite entertaining, and admire your skill in
surpassing your own previous record levels of complete nonsense.