If your desktop box isn't a wimpy laptop or dumb terminal, you should be able to run a temporary database locally, without giving it any access from the network or using external resources. Worst case, would you be allowed to use something like DBM::Deep with a flat file?

Collect your set of scripts for importing the various types of datafile you commonly see, and run those on demand during the meeting. Once the meeting is over, drop the whole database.

So when the meeting happens, you fire up the database, doubleclick your "import_feedfile.pl", and then run the first query. Question 2, you change the query. Question 3, you doubleclick "import_downstream_feedfile.pl", and then run your new query. Rinse and repeat.

IE: Don't have scripts for one-off filtering, only keep scripts for importing the various files you'll see more than once, and do your actual queries with SQL.

Our desktops are actually little more than X connections with MS Office running. Attempting to install anything that trips microsoft's "installation" system is locked out, as are writes to most of the local disc and any external devices.

I like the idea of using something like DBM::Deep. But have never used any of those, so it's new stuff. If I can inject custom parse routines into them (the data formats are never quite so simple as plain csv, and certainly not fixed-record files) then it's definitely a candidate.

Me

I write this as your friend, and Your Mother, start circulating your résumé. There is nothing wrong with shopping around and the mere fact of having options can make a sub-optimal situation easier to handle.

Is running anything off a thumb-drive locked out too?

If not, some "Portable apps" are real life savers, such as a full fledged XAMPP stack. You load your thumb drive on your home machine and sneak it in using this tiny USD drive.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

... it's a near firing offence if I do it as a skunkworks project and they won't allocate it willingly.

Can you use DBD::SQLite?

Certainly not legitimately. The allergy to external code here is silly. But frankly I need to solve the problem, so that's not going to stop me if I can help it.

But that's a question best answered by experimentation. The trick with sqlite is getting it installed in the right place.

Me

When you have a legitimate need, management is likely to listen; especially when you can put a cost to how much is attributed in manhours/salary to routinely solving similar "recursive" problems.

I would suggest you discuss having some sort of development area where you could tackle such a task. You have a lot of data, so you probably need a better db engine, but if they aren't willing to give you the tools you need, perhaps you could daisy chain a few JET (MS Access) databases, to have something a little more robust and scalable.