File Selection Program or Database for Non-CAD Use

[CEHill]

I am a software and programming novice but have a need...

It would include a sleek GUI (front end) with an icon-driven dialog box that would allow non-CAD technical staff to select a manufacuring-related document i.e. a process diagram, schematic, equipment specification doc, or even a 3D model.
I am clueless on which type of more modern programming languages and/or software platform would provide this 'slick' front end.

This 'light' application would inititally support a local company with a user base of less than fifty technical users in a chemical processing plant.

The back end would necessarily be a database that would manage an electronic repository of the various documents - possibly MS Access 2010.
I anticipate that most of these documents would be stored as PDF, DWF (for 3D models) and in image file file formats.

[cadtag]

That sounds like the description for an EDMS, Engineering Document Management System You could spend a couple million US$ writing a proprietary version, or license one that some has has already spent the money to develop. Adept, from Synergis Software would likely meet the requirements.

[CEHill]

I have explored those excellent options. We an excellent EDMS that is in use by another department but is frowned upon by my engineering manager.
Mine would not be managing documents per se: no revision control, etc but would essentially be a much-needed search tool and file viewer inside a database and would be very limited in functionality and scope.

Would anyone have experience in developing a similar type of application?

[Wanderer]

I have explored those excellent options. We an excellent EDMS that is in use by another department but is frowned upon by my engineering manager.
Mine would not be managing documents per se: no revision control, etc but would essentially be a much-needed search tool and file viewer inside a database and would be very limited in functionality and scope.

Would anyone have experience in developing a similar type of application?

I just did it with Access... Used simple forms and queries.

If I were doing it today, I'd build an app in Visual Studio with a sql backend.
The drawback to Access (at least back when I built this... a decade ago ) is no dropdown ability, so people actually have to know how to spell a little.

Access Form
ScreenShot328.jpg

Data Collection Program
ScreenShot329.jpg

(sorry, I know the 2nd example doesn't show a hyperlink, that's just the last program I wrote that does data collection... and, it was a team effort, I never would have picked that hideous background color )

[CEHill]

Melanie: You really should win a prize!!! I really appreciate your images and advice on how to proceed with this effort.

While I thought the 'map' - just picture a dialog with lots of buttons on how to proceed with a search - was initially a good idea. In actuality, I couldn't have picked a title as misleading as the one for this topic.

[Ed Jobe]

The drawback to Access (at least back when I built this... a decade ago ) is no dropdown ability, so people actually have to know how to spell a little.

Melanie, don't just call the query and let it prompt you for a parameter. Call a custom input form, then pass that data to the query. You can design the custom form however you like.

The main reason for going to sql would be for multiple user access. But to keep it simple, Access is fine. To prevent file locking issues with Access, I just finished one with a back-end/front-end. The front end links to tables in the back end. That way multiple users can have the gui open (a copy on their pc) and access to the back end is handled at the record locking level. But if you did go to .NET and sql, you could make use of data binding and workflow. On the other hand, Access is easy to generate reports for. It still has its place.

[CEHill]

Melanie, don't just call the query and let it prompt you for a parameter. Call a custom input form, then pass that data to the query. You can design the custom form however you like.

The main reason for going to sql would be for multiple user access. But to keep it simple, Access is fine. To prevent file locking issues with Access, I just finished one with a back-end/front-end. The front end links to tables in the back end. That way multiple users can have the gui open (a copy on their pc) and access to the back end is handled at the record locking level. But if you did go to .NET and sql, you could make use of data binding and workflow. On the other hand, Access is easy to generate reports for. It still has its place.

Ed,

I feel that for the smaller scope and number of intended users, MS Access 2010 will fit the bill nicely. Your tips are soaking in.

A nice-to-have feature would be the ability to open a PDF or possibly a DWF (for viewing a 3D model) included in code from within the database application. I would prefer to code a solution and not rely on those expensive third party goodies.

[Ed Jobe]

For opening a doc, just include a hyperlink field to store the path to it.

Fair warning though...there's a reason they're expensive. I thought about doing my own years ago too. But the project scope can easily outgrow your ability to maintain it. If you go the homegrown route, expect to stay simple.

[Wanderer]

Melanie, don't just call the query and let it prompt you for a parameter. Call a custom input form, then pass that data to the query. You can design the custom form however you like.

The main reason for going to sql would be for multiple user access. But to keep it simple, Access is fine. To prevent file locking issues with Access, I just finished one with a back-end/front-end. The front end links to tables in the back end. That way multiple users can have the gui open (a copy on their pc) and access to the back end is handled at the record locking level. But if you did go to .NET and sql, you could make use of data binding and workflow. On the other hand, Access is easy to generate reports for. It still has its place.

Ed, Thanks. I'll keep in mind if I ever decide to revisit.

Multiple user access is a concern here. Most folks don't use the database, except from one of our shared workstations, but, as our workforce gets a little younger (not to be ageist, but, the younger mechanics are more willing to do their own searching and demanding more mobile access to the data we have), I'd like to at least prepare for the possibility of all 200+ users accessing the data.
We don't store anything locally on users' machines currently, just on the network. It's hard enough to get them to remember to have IT install the other programs they need, let alone porting over files for them, and I'm only one person, I can't monitor the constant refreshes myself.

Chillme1,

It sounds like Access can do it for you. The hyperlinks, like showing in my first screencap, go to any filetype, dwg, pdf, word... I don't have any of the rvt files in the database, though, as we've only two seats of it, so people have to call me to export those for them (to dwg or pdf).

[CEHill]

Melanie,

Any effort will have to be necessarily simple in scope and must be on my guard to keep it that way. MS Access 2010 will be the chosen application. Scanning older board drawings as well as making available CAD output for staff as PDF files will greatly simplify viewing and plotting. Adding the resulting PDF's to the database will help keep things simple. As far as updating drawings, all of them come through me so revision control is not an issue.

As the person with the widest variety of design experience (all except civil) and with the most in-depth AutoCAD experience here, this is truly a unique position that I am currently filling. I have a locally-based and supportive company IT techie and open-minded engineering manager that keep me supplied with near cutting edge hardware and any requested software. All full-time CAD designing is done by yours truly in a smalll engineering support department that is part of a global corporation. I like coming to work!