Just interested really to find out others views on what are the "To Die For" features or "Icing on the Cake" that really makes your own database system(s) great?

Considering this is a whole forum on databases, the content is a little sparse.

If we share a few ideas they could go a long way in developing excellence.

I suppose a flippant answer might be:- it is always nice when they actually work!

Like you, I have seen a fair number of (expensive) proprietary equipment database systems that require a lot of "nursing" in order to become anything like efficient. At one place I know, a senior biomed* is employed full-time to run the "system". Nice work if you can get it, I suppose, but surely not a cost-effective solution.

Regarding the "wish list" ... again as you know, that may well vary considerably from site to site. A "one size fits all" solution is both difficult to achieve, and perhaps also less than ideal anyway.

As I've said before, a good system needs to be highly configurable in order to suit specific needs.

Regarding collaboration, we've tried that a few times on here before, but have yet to produce anything of lasting value. Frankly, I feel that (to many) the whole idea of biomed databases may have become "old hat".

* Just to be clear, I'm not talking about Lancaster!

Geoff, thanks for the sentiments! I hope we can stir a little response. I like to hope that biomeds have unique needs and therefore should not come under shadow of estates maintenance packages.

I will add my 2p worth from the top of my head:-

- Geenrate Letters & E-mail functionality using word templates
- Hard access to my data through msaccess/crystal etc
- Export to excel from various views
- Contract management functions - With attach documents
- In fact attach documentation or text comments to everything - Assets, Models, Equipment Types - Anything that will help in the future.

What features of your systems do you think are not mirrored in others?

There are quite a few CMMS companies out there, so I decided to put specifications together for BME, then with the assistance (not yet delivered) of the 'estates' people there specifications will be added, contracts, purchasing, projects etc. then we will forward these to the various companies to see if their software can be modified to our requirements instead of learning a whole new system. The current system developed by IT absolutely SUCKS!!

As I keep saying, Neil ... do it yourself (in-house)!

@Joe: yes (again as I may have mentioned before) ... a "bare bones" (but robust) database, filled with accurate and up-to-date information, but expandable as (when or if) necessary, and with all the hooks in place to be able to link here, there, and everywhere!

Geoff, IT control the network and the computers, therefore I have to get something for the whole of maintenance, politics will not allow us to submit our own as we cannot make IT look stupid and inept.

Yes, Mate. I hear you.

My stuff already does basic exporting (to .dbf, .txt, .xls, etc.) and importing (but only to *CSV files for the importing routines). As well as being able to **link (where appropriate - eg, service manuals in .pdf) to other documents, as long as these are accessible in some way to the host computer being used ... plus a number of "features" (not to mention bugs) rarely found in "off the shelf" packages.

I reckon I'm more or less at the end of the road now as far as actual nuts and bolts coding is concerned. But cosmetic "improvements" aside (and I'm really more interested in functionality), an ability to output via templates to Word may well be worth a visit.

Sad chap that I am, I hope to spend time over the Christmas / New Year / Midwinter Feast / Holiday Season / Office Parties / Winterfest / Ground to a Halt Fortnight / Multi-Faith Rest Period / Hibernation / Bank Holidays (whatever) happily coding away. If anyone wants (needs) my latest stuff (and until I get Huw to post the latest revision in the Downloads section), feel free to get in touch.

Meanwhile, and in regards to Joe's original question(s) at the top of this thread ... does anyone else want to say a few words?
______________

* Which is probably sufficient, I reckon, as any external software package worth its salt can usually send output to CSV text files.

** Using either Hyperlinks (eg, to URL's) or the format file:///c:/manuals/pumps/manual.doc as appropriate.

Your comment about Word Templates has reminded me about Surefire, Joe. As they say, there's nothing new under the sun. And what was wrong with DOS, anyway?

My stuff already does a rudimentary filtering of (up to *five) database fields, selectable by the user, and directing them to text output. So, if you have a couple of your nice Word Templates that you could bung my way as examples to have a play with, I might look into having a go.

Meanwhile, Crystal Reports looks like **"spending money" to me! I haven't had a go with Crystal for many years. Do current versions accept input from Good Old .dbf files?
__________

* At "design time", I reckoned that five fields was enough for most needs (especially considering that many pre-formatted reports are also available within the system), but more could be added if need be.

** As in ... at least £ 400 plus!

Hi Joe,

Long time since we spoke (9fd wksp).
Currently we use Access 2003 tables, but our trust is currently in the process of getting Backtraq to use as a database system.
How reliable or effective it will be will be determined over the next few months.
I remember the system we had at Haslar that you and Steve developed but that required one of you to keep overhauling it on a frequent basis.

However brilliant (and expensive) it may be, it is very unlikely that any "off the shelf" database will prove to be all things to all people (biomed departments, hospitals).

In your case, Steve, you may even be better advised to stick with Access, and couple it with InfoPath (Billy's favourite) and/or Word templates (Joe's).

But, as you suggest, with anything like that, it's always nice to a have a bloke of Joe's calibre on hand to keep the thing going, and develop it further as the need arises. And, and you probably already know, it always does.

I've got quite cynical in ways regarding databases but I'd say its a fair point regardless that I have to say.

In a strange way you could say that ANY DATABASE WOULD WORK for our EBME colleagues. What I mean by this is that it would store information/attachments/links and whatever else you want to bury away into electron land.

Yep, that’s right, Msaccess, Excel and anything else loosely badged a database would do perfectly.

But... of course it would be no good because were not actually bothered about the database, we are bothered more about the retrieval of information and the tools that enable us to manage equipment.

Steve’s post and a few others talking about the management of the database requiring a lot of work should be a thing of the past! (other than the odd admin tweak or user modification of templates etc).

My own thoughts are that it is much more important for the software to be designed in a complimentary automated and streamlined manner!!

When looking at equipment procurement we evaluate both purchase/capital costs as well as running/service costs. If we applied the same robust principles to database procurement then we should evaluate not just the functionality of our database but the time-efficiency of completing tasks within it and the ease of use for a novice user.

Over the duration of your partnership with the database it should more than repay you that time back in efficiency, something we should all be looking to do given the press on the NHS for streamlined management, increased litigation and less staff

^^ Not a rant in the slightest, but hopefully a little beneficial to any wishing to evaluate or develop databases in the future.

Off the shelf you may be struggling to meet your entire needs, however if you can outsource 95% of the system to an off the shelf then you could concentrate a little on the 5% thats missing and ADD it though exports/reports etc.

Yes, I agree.

"One size fits all" can only mean ... "compromise" (and sometimes a great deal of compromise at that).

After a while all those knobs and whistles are likely to clutter up the whole thing with "features" that not everyone needs. When that happens, I suggest that it's time once again to return to First Principles (and yes, any old spreadsheet or *database manager will do).

The trouble is that as far as "biomed" databases are concerned (as it is with almost any other), there are people out there who are trying to make Big Bucks out of selling the Perfect System.

But if you evaluated the need and then looked at what was (is) available as you suggest Joe, my guess would be that (for most situations), that Perfect System (perfect fit) does not actually exist right off the shelf. So it's back to Home Grown (bespoke, whatever) supported by informed tinkerers like ... well, yourself Joe!

Either that or expensive proprietary systems that have to be constantly adapted (made to fit) ... usually by the same clued-up member of staff.

Your last point about the missing 5% is spot on. The Law of Diminishing Returns? Tell me about it! Not so sure about "a lot of work should be a thing of the past", though (although I appreciate that you're talking about that from the Power User's point of view - I think). Someone still has to be able to set it all up, and apply the tweaks as and when they are called for.

* dBASE III Plus will run happily in a Windows DOS-box, you know!

Surely a open source project written using modular programming could fit the "One size fits all" category without being a compromise?

Just a bare bones system to start with, adding the knobs and whistles as modules that could be either selected at compile time or run time.

Go ahead Chris ... then we shall see.

I have tried on here a couple of times before to seek the consensus about what is required. No joy yet, though.

In my experience, when it comes to software projects, "design by committee" just ends up with a bloated mess (with very few willing to do the actual work).

But with a small, tight, group of the right sort of people, perhaps what you're suggesting is "do-able".

Any volunteers?

1) Equipment Inventory
2) Open Close Service Orders
3) Generating PPM Service Orders
4) Equipment History Files
5) Depreciation Evaluation
6) Down-Time Evaluation
7) Contracts
Next Please

8) Parts?
9) Reports?

Not too much to it, but lots of ways of achieving the same results and that is where the problem lies.

I managed to create one for managing all the equipment in the hospital I am working in using MS Access. Thankfully I do have some VB knowledge as well, so it wasn't very hard for me to throw in some automation for reports and stuff.

Oh and just add, I'm also creating a little Android client for my on site needs so I can sort of "check in" the fault while being with the staff.

That's the spirit!

As with vegetables (and chickens?), "home grown" is always best!

Welcome to the forum, by the way.

Thanks for the welcome. I guess I'm just fortunate that I have a very strong programming background because of my own interest. I wonder how many users here have an Android phone? Would be nice to be able to justify uploading my beta onto the marketplace.

Vulpix,
I have an andriod phone..will you be adding the barcode scaning feature too?

The problem of course with locally generated databases is that it's usually someone's 'baby' and they're quite precious about it. Therefore, when they go they tend to keep things like passwords to themselves and you end up stuck again (in my experience).

Yes ... we've heard about that sort of thing before, Jocky.

But I would say that your experience has been unfortunate, as not all "home grown" stuff is password protected, and some it may not protected at all (that is, can include source code for others to fiddle about with).

Anyway, why aren't you writing your own?

"Precious"? "Anal" you mean? There's no reason to password protect software unless you're selling it (and not even then, in my opinion). The only valid reason for password(s) is to protect access to the data.