If your only reason for using Access is that you can get it for free, don't use it! Use MySql or Postgres. At work, we have several Access Databases that we use to track Trouble Tickets of various flavors. The DBs are constantly corrupting themselves and need frequent restores from tape backup. Don't lock yourself into this sort of mess.

Now that I've said that, what you are discussing is definitely possible to achieve with Perl. I can't really comment on writing traditional GUIs with Perl. But I will advocate for a browser based app.

Browser based apps written in Perl (or other P* language) have been dubbed LAMP, for Linux-Apache-MySql-P|(erl)|(ython)|(HP). They have some nice advantages:

• Price: All your tools are free.
• Scalability: You can build a system that can handle 1 or 1000 clients.
• Server Based: You don't have to install/maintain applications on multiple PCs.
• Rapid Development.
• Familiar interface: People are comfortable using their browsers and tend not to think of web pages as separate applications.
• Modest sytem requirements: I run Linux with Apache/mod_perl and Mason on my dev server - A PPro 200 w/ 96 MB RAM. I just wrote a forking webcrawler and that wimpy box can handle 3 hungry connections continually pulling dynamic content without excessive swapping, more RAM would make things better.

If you go with a browser interface, you should consider using some sort of templating system. Template Toolkit comes highly recommended, I like Mason, and embperl is popular. Some careful use of Super Search should turn up some sound info on your options. You may also want to look at tools like Zope or some of the PHP based site builders.

BTW, I never thought I'd see so many Perlmonks recommend using VB :). I haven't used it much, but it looks like it's got some great interface building tools. If one could hook up a VB interface to a perl app...

TGI says moo

After a lot of attempts to improve performance, I started evaluating the possibility of a Win32 native interface, using the same PERL back-end code. Luckily, I found some interesting tools that speeded up Win32::GUI development, and I am beginning to get much better performance due to the lowering of load on the server.

Here's what I use:

1. The GUI Loft
   by Johan Lindström is an excellent VB work-alike that for designing GUI forms. It creates a Dumped version of the GUI, which you can load up using couple of lines of PERL code (see above URL for details).
2. Johan has also designed another Win32::GUI app called Oasis which works as a neat code and POD browser.
3. I am still using HTML to create outputs (reports, listing etc), for its much easier to format these in HTML than in Win32::GUI. The easy way to do this is to save the HTML to disk and invoke the browser. A neater, but not as easy alternative is to use DDE.
4. PERL has several Template interpreting tools to help generate HTML outputs. I've tried HTML::Mason and Template-Toolkit and settled for the latter - its really neat.
5. Data is stored in MySQL on one of the machines, and called via DBI.

Hope this helps...

- Ashutosh

this whole project is a voluntary free service i am attempting to provide to a small family owned and run niche-market store

With all due respect to my esteemed brothers who suggested mysql or postgres, those both seem like overkill for this particular application.

This is Mom and Pop type business, which I interpret to mean that multiuser access and scalability are NOT serious issues here. Further, Lord Wrath's inclination is to go with VB and Access, which, while not my personal choice for such things (Never ever!), seem from a distance at least appropriate to the job.

So all things considered, before even discussing a possible Perl-based solution, I'd expect a reasonable impedance-match between these particular requirements and a VB/Access-based implementation.

That said, it's less clear why alternative strategies are even being considered. Perl? C++? What seems to be required here is a short development time (so forget about C++), and no development costs (other than time itself). Perhaps the motivation is personal, as in wanting to develop something in Perl?

Developing a solution in Perl could (broadly speaking) go one of four ways:

• Command-line driven (probably not an option, really)
• Local GUI such as Perl/Tk, Win32::GUI, et al (May be more work than it's worth if there's a learning curve involved)
• Web-based GUI, or CGI
• I'm sure there's another option, but it escapes me

While my own preference might be to go with a web-based approach, using Apache, CGI and some sort of simple database accessible from Perl (like, say JSprite, the standalone version of DBD::Sprite, which uses a CSV-like text-based file format--no need for the overkill of even a small RDBMS), I have to say, despite my own personal biases, that I think the VB/Access approach offers the greatest bang for the buck on a project like this.

To wit, If ever there comes a time when the business expands and they need to migrate to a (gasp!) purchased system, there seems to be a much greater likelihood of being able to find a VB programmer who knows Access to decipher what you've done (presuming you yourself are not available), than an Apache/Perl/CGI programmer who is comfortable enough (and willing!) to work with the PC as a platform.

While I am all too aware of the forum we are in (who here hasn't experienced the "When all you have is a hammer, every problem starts to look like a nail" Syndrome), I have to answer your question honestly, and this just strikes me a an obscure application for Perl.

dmm