Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

A Database for the Office? 156

Posted by Cliff from the something-to-start-small-and-build-on dept.
travellerjohn asks: "I work in a small company (200 people in 7 offices), where the staff uses Microsoft Access to create various databases. Most of the time they lose interest before the databases become complex or important enough to warrant the IT department getting involved. However, from time to time, someone turns up at our door looking for help with their pet project, often starting with statements like 'it should work over the intranet' or questions like 'why can't it store documents and pictures?' or 'how do I control user access?' When we sit them down and explain how much it will cost to rewrite their database in PHP/VB/JSP, or whatever we sound unhelpful and expensive. What database tool does Slashdot recommend I provide our staff? It has got to be easy to use, web enabled, capable of storing documents and pictures and offer user level security. We have tried Sharepoint with some success but that is pretty limited, too, and I have looked at Oracle Application Express. Open source would be good, but I would pay for the right product. Any suggestions?"
This discussion has been archived. No new comments can be posted.

A Database for the Office? More

A Database for the Office?

Comments Filter:

  • So wrong it isn't even right? (Score:3, Insightful)

    by hackwrench ( 573697 ) <hackwrench@hotmail.com> on Wednesday June 14, 2006 @10:02PM (#15536977) Homepage Journal
    It seems like the work flow (what's the right term here) is out of whack there. Database projects that "lose interest before they become complex or important enough to warrant the IT department getting involved"? It reminds me of the commercial where they discover they don't have any computer problems so they can refocus on the real purpose of the company.

  • What about a webserver? (Score:4, Informative)

    by SeeMyNuts! ( 955740 ) on Wednesday June 14, 2006 @10:03PM (#15536979)
    "It has got to be easy to use, web enabled, capable of storing documents and pictures and offer user level security."

    Is it hard to set up an office webserver with some sort of content management that everyone can use?

  • Take another look at Sharepoint (Score:5, Informative)

    by ednopantz ( 467288 ) on Wednesday June 14, 2006 @10:06PM (#15537005)
    A relational db is one thing, a document collaboration tool is another. If it is a MS Office environment, get someone who knows Sharepoint to come out and show you and one of your power users what it can do. You can even buy/build modular web parts if your document needs are out of the ordinary.

    You'll need MSSQL on the backend, so that solves your "bigger than Access" problem right there. These tools dominate their markets for a reason.

  • Claris FileMaker (Score:5, Informative)

    by sakusha ( 441986 ) on Wednesday June 14, 2006 @10:08PM (#15537017)
    FileMaker seems to be the easiest for non-techies to grasp, and supports image storage, publishing to web servers, and other goodies they want. Also hooks to SQL if you need more horsepower on the backend.

    • Re:Claris FileMaker (Score:4, Informative)

      by misleb ( 129952 ) on Thursday June 15, 2006 @02:54AM (#15538156)
      I'd have to second this. Filemaker has come a little ways with FM 7/8. It now has centralize authentication (auth against ActiveDirectory). Has web publishing capabilities. And if you really need to, you can pull data from it into a "regualar" website via FX.php. I, personally, wouldn't use Filemaker because I'd rather use a "real" development environment like Ruby on Rails for database driven applications. But filemaker seems to work well for people who can put together MS Access type stuff.

      As for SQL support in Filemaker though, I must say that it is pretty poor. As far as I know, Filemaker can only IMPORT from SQL sources. It can't access them live.

      -matthew
    • Having spent the last 2 days trying to get their simply retarded 'Web Publishing Engine' working on a fairly standard OS X install with a perfectly happy FileMaker Advanced Server 8 database server that is also installed there, I cannot recommend this as a great solution. Their technical support people seem to have the 'resintall, reboot' mantra firmly embedded in their heads and no amount of talking to them has made me think that they are adquately trained to support their own software.

      YMMV

  • Lotus Notes (Score:3, Informative)

    by omibus ( 116064 ) on Wednesday June 14, 2006 @10:15PM (#15537048) Homepage Journal
    Never thought I would say this, but if documents, images, and security for a web site are your main consern: Lotus Notes.

    Easy to use with a little bit of training, and works wonders with documents (suppost to be better at it than sharepoint)
    • I second Lotus Notes/Domino. It is a very rapid application development tool. Only downside seems to be a somewhat awkward user interface but when you develop web applications, your users won't see the Notes client anyway.
    • Absolutely consider Lotus Notes. It can be simple enough for nearly anyone to develop with, yet can be complex enough for most any workflow application. Also, its security is second to none. It allows control to be as granular as you would like - down to the field level. Yes, the client does have a non-standard interface, but it can grow on you too. Using the client allows for fairly easy development of some quite complex applications too.
    • I'll give a third nod to Notes.

      This is what Notes was designed for. Everything is a database, and it's just as easy as in access to create nice little front-ends for them. Plus it was designed to be stable and secure in multi-thousand user environments.

      Notes got a bad rep, because they put the Notes v4 UI up against Outlook when they tried to compete against exchange. The UI isn't that sucky anymore, and Notes does 10x more stuff than Exchange, so it's not even close to a fair comparison. Unfortunatly, once
      • Just curious... After having worked with a fairly large organization for a number of years it seemed like any applications using Notes needed a certified notes developer to create anything useful. Since they were in short supply on the IT staff, Notes applications seemed to take quite a while to get rolled out. Even for using directly as just an email application, I have found Outlook far easier to set up simple filters and mailboxes than with Notes.
        • It seems pretty easy to me, but then again, I used to work for Iris as a Notes/Domino developer (developing the product itself, not databases that run on it), so maybe I have an unreasonable perspective.

          Experiences with it as an e-mail application I would say give poor representation as to how it would function as a database manager. The e-mail functionality in Notes is implemented as a Notes database application, and the shortcomings you describe are not something that would have to be translated into pain
    • Ok, I concede that Notes can do all the poster requires, but "little bit if training" is the worst exaggeration I've ever seen on Slashdot. Programming Notes is a monster, and only the half-insane would even attempt it. Notes/Domino is expensive as heck, and Notes-certified developers command a steep price. In addition, the application itself is bloated and slow, and has an arcane impossible-to-like UI.

      Give it a try if you must, but I doubt you'll find a single user who enjoys using the program.

      Plus, onc
    • The whole concepts of documents, views, folders and forms make total sense once you get your head around it. Also, for a business person, they are so much easier to get than relational data.
      It also has simple actions for most business type stuff and it is dead easy to create a new database from a template.
      A good IT department can provide the users a selection of templates to base their ideas on. If you let the business users prototype some solutions, you will probably be able to help them take it to the nex

  • Try a CMS? (Score:1, Interesting)

    by Anonymous Coward
    I think what you want is a CMS system like Metadot, not a database. If users are looking for an easy way to share images and documents, a database really isn't the best solution. Hell, a shared network drive would be better than a DB.

  • FileMaker (Score:5, Informative)

    by doj8 ( 542402 ) <doj-sdNO@SPAMnewww.com> on Wednesday June 14, 2006 @10:19PM (#15537062) Homepage
    I've used FileMaker quite successfully for many years. It is simple enough for most folk, but extensible. It can store pictures and other binary data. The web interface can be customized. User level access control is built-in. It runs under Windows and Mac and in Wine under Linux. Databases can be migrated to a FileMaker Server, if they go beyond the standalone limits (10 simultaneous users, typically). There's also a compiler to create standalone applications from databases, without needing a license per user.

    All in all, FileMaker is a great tool for this sort of thing.

  • Yep... (Score:3, Funny)

    by mmortal03 ( 607958 ) on Wednesday June 14, 2006 @10:24PM (#15537090)
    "Most of the time they loose interest" As opposed to "tight interest"?
  • Why not try Groove? It's owned by Microsoft, and likely to show up in future versions of the OS. It's fairly easy to use, and you can store whatever you like securely.

    • Re:Groove? (Score:2, Interesting)

      by baldass_newbie ( 136609 )
      With SharePoint 2007 there should be tighter integration as well and it will cover ALL of these requests.
      I admit SP doesn't look like much now, but as you dig and see the Object Model, how it can be integrated into user environments, workspaces, audiences, etc. - it's quite powerful.
      No, I'm not blindly pro-MicroSoft and they've still got a long way to go (apparently SP07 slices bread, too) it's just that I can see how MicroSoft is going and it's going to clean Linuxes clock for collaboration.
      Coincidentally

  • Rethink the Process (Score:5, Insightful)

    by moehoward ( 668736 ) on Wednesday June 14, 2006 @10:26PM (#15537101)

    In a 200 person company, I would get rid of Access on the desktop. I see the appeal, but it's time for the IT department to step up and consolidate database development/maintenance so that it is more centralized.

    Once IT takes control of all databases, all sorts of things fall into place, such as security, backups, moving to a single technology (SQL Server or MySQL), etc. At first it is a bit more costly and people will complain about losing flexibility. But in the lgng run, it is cheaper and people who do OTHER work will find it nicer to be able to focus on their core expertise.

    • Re:Rethink the Process (Score:5, Insightful)

      by Tablizer ( 95088 ) on Wednesday June 14, 2006 @11:26PM (#15537429) Journal
      but it's time for the IT department to step up and consolidate database development/maintenance so that it is more centralized.

      In theory this sounds great, but the problem is that the centralized place becomes a bottleneck, sort of like "free"-ways. It gets overworked and delivery times start to slip. If a smaller department has control, then they can decide how much resources and effort to put into things on a case-by-case basis and ramp up quickly if needed. Yes, it results in more duplication, but sometimes that is preferrable to lack of service response.
      • That bottleneck is not a problem with the theory itself, but rather a problem with a different theory: How much funding IT deserves.

        If IT runs out of human resources whenever they proactively "step up to the plate", they are underfunded and will forever by acting in a reactive role, hence the bad image in the workplace.

    • Re:Rethink the Process (Score:5, Insightful)

      by DuctTape ( 101304 ) on Wednesday June 14, 2006 @11:46PM (#15537524)
      Once IT takes control of all databases, all sorts of things fall into place

      Where I've been, once IT takes control of the databases, you never see them (or your data) again.

      DT

    • Centralized DB in even the MySQL style is serious overkill and overcomplication, for casual or local very-denormalized data listings such as constitute a the majority of small-business databases. Access would be good if it were cheap and you could trust it. Excel is a common ugly hack.

      Perhaps there's some GUI tool based on SQLite?
    • Corporate IT taking control of all database activity is an insane idea. The whole point of hirng intelligent people to to let them try ideas. Most ideas will be a total waste of time but the good ones make the whole exercise worthwhile. By all means let IT manage databases that support good ideas but please don't cause the IT department to stifle the creativity that makes innovation possible.

      By way of example, I worked in Vodafone's global HQ where a system for billing premium rate SMS was developed and

  • TWiki or some other internal wiki? (Score:5, Informative)

    by allenw ( 33234 ) on Wednesday June 14, 2006 @10:31PM (#15537127) Homepage Journal
    Why not use something like TWiki? It can store those things plus it has decent enough access control. We've moved almost our entire business unit (around 600 users) web content and migrated a lot of processes to one centralized TWiki installation running on a Solaris box and couldn't be happier.
    • I was thinking along the same lines. I guess it would matter on how much data needed to be stored vs images and documents, but if you move towards the out side of the box, you might be able to use a social networking system to do a lot of the work for you. Seems kinda screwy to think of MySpace as an enterprise tool though ;)

      -Rick
    • I've installed a Wiki at work for collaboration. Most ignore it (and bitch about the lack of collaboration tools), but a few use it. Ideally, you'd want to tie in a filter for MS Office documents, so that people could upload Word or Excel files and have them rendered (much the same way Yahoo's e-mail can - well, some of the time). There are a LOT of wiki systems out there (MediaWiki, IkeWiki, etc) which are good at different things. If this sounds like a good approach, then I'd suggest doing a little resear
      • The key to wiki adoption is all about critical mass. Encourage people to experiment on their own rather than telling them how to do it. Encourage them to use it for their own purposes. Keep up on RecentChanges and be sure to add useful things to stuff other people are working on.

        I've had big successes at two companies, but you have to make it super easy to get into, and you have to be encouraging, and it does take time.
      • I think this is why the grandparent suggested TWiki. Like anything else, if you don't market the product, people won't use it. At our company, everyone loves the wiki. When there is a critical mass of data on the wiki, people start relying on it. People always ask questions like, where was that document on hiring interns? oh it's on the wiki! I'd say TWiki is a pretty powerful system, and handles everything the other wikis can do. TWiki standalone can already replace most CMS systems. If you use TWi

  • Solve next years problem as well as todays... (Score:4, Interesting)

    by riprjak ( 158717 ) on Wednesday June 14, 2006 @10:36PM (#15537150)
    ... BAN Access. One day the database "created just for a simple task" may become the repository of mission critical business data. Access is inappropriate and incompetent to the task of being a "database" in any meaningful sense of the word.

    Training is critical; ensure staff recieve spreadsheet (excel or your chosen open source brew) training in reasonable depth... Then encourage them to use spreadsheets for "simple tasks" involving data storeage. Making some "standard" macros for query dialogs is useful here. Then if the data does become important, it is a trivial task to move it into a real database (unlike access!).

    One solution I have seen effectively used is the creation of a "general" database using mysql and a rather clever PHP front end. The database allowed for 8 "fields"; each field was really three fields, Data descriptor, Data name and Data type. Essentially the ID-10-T entered a name for the data field, its data and selected a type from a drop down box. They could select previous "name and type" combinations they had used. This then spawns a copy of this "standard" database with user access privelges set to a default rule; another interface allowed advanced users to adjust this. Finally a generic PHP gateway presented them a data entry/query sheet that formatted itself based on type... Sure, it was probably alot of work, once; but it ensured that all future databases created were in "real" databases that were relatively easy to maintain for the IT department.

    Essentially, my suggestion is to encourage them to work with excel or similar with a few standard macros/dialogs created to allow data entry and search to be "simple" (small up front work by IT, maintenance required); or create a more complex "standardised" database and access system (alot of up front effort, minimal maintenance). This trades effort for ease of future scaleability and maintenance.

    Just my $0.02
    err!
    jak

    • Re:Solve next years problem as well as todays... (Score:5, Insightful)

      by ednopantz ( 467288 ) on Thursday June 15, 2006 @12:38AM (#15537767)
      Holy crap. Moving them from Access to Excel is a good thing? Are you nuts? If you don't like rogue Access apps, the solution is to offer a better solution, not ban the technology that comes closest to solving their problems.

      Assuming there aren't internal resources, get some broad guidelines for those rogue people and better yet, cultivate a stable of smart outsiders who can be the "approved" rogue IT for when business people bypass IT and do their own thing using Access. If you are going to have rogues, have good rogues.
      • Ahh! not quite.

        Move them from Access to SQL or something. If you want to allow "rogue" data sets; I much prefer a spreadhseet; creating a macro to allow a pretty front end for data query and management is trivial and the underlying document data is *significantly* less fragile. Recovering data from them years after the fact is easier, converting the data into a manageable dataset within a "real" database is easier etc..
        This is, of course, IMHO; but, I can see no meaningful arguement to ever allow MS Acce
        • Huh? Have you ever actually used Access? It uses SQL for all data extraction and can use SQL server (or MySQL for that matter) as a back end. Access is a front end tool, and rather a good one at that. "Jet", the default back end, can do such things as subselects, something that came rather late with MySQL.

          Don't confuse Access the tool with all the people who use that know nothing about structuring data well. You can normalize data in Access as easily as you can in any RDBMS.
          • Well there you go. No, I hadn't personally used access for many years... I have only ever undone damage done to businesses caused by ID-10-T's using access inappropriately; and, in times past, confronted braindead design ideas like 2GB file size limits that broke databases, although a colleague has just informed me that this limit came from the OS...

            That *IS* interesting and now I have another bloody tool to go and learn about! I suppose I should have realised it was possible for the product to evolve an
        • Move them from Access to SQL or something.

          Great idea! Shall we also move them from Word to C++? I hear C++ has a much better spellchecker!

    • One solution I have seen effectively used is the creation of a "general" database using mysql and a rather clever PHP front end. The database allowed for 8 "fields"; each field was really three fields, Data descriptor, Data name and Data type. Essentially the ID-10-T entered a name for the data field, its data and selected a type from a drop down box. They could select previous "name and type" combinations they had used. This then spawns a copy of this "standard" database with user access privelges set to a

    • There are people in the world who need to be able to model data quickly, and on their terms. They are called business analysts. With a tool like Access, they can do their jobs. How do you propose they do their jobs when you design a black-box PHP/MySQL application? Are you going to provide them with the tools they need to create their own views and extract data for analysis? Are you going to provide them with a dtaa warehousing/reporting solution that gives them the flexibility they need?

      Programmers v

  • Teach them SQL? (Score:2, Insightful)

    by miyako ( 632510 )
    You could always set up a MySQL server with PHPMyAdmin and have them learn SQL....
    On a more serious note, you might just consider rolling your own application. Set up a MySQL (or Oracle, or MS SQL, whatever you like) database, then roll your own application that will meet the needs of the various departments. Keep tally of the features that people are asking for on their specific projects, and include the most common ones. Once everything is finished, then just allow departments to port the database ove
    • Umm, I think developing custom applications on top of SQL is exactly the kind of expensive thing they were looking to avoid. Although I don't know that there is any way to avoid it. Consolidating data and writing effective interfaces that work for everyone is not a trivial task. Sure, there are RAD tools that can speed things up, but at some poitn you are going to have to bring in SOMEONE who knows what they are doing. A couple IT guys and some users with MS Access skillz just isn't going to cut it.

      -matthew
    • Nah you don't want them to do this... some people will always take shortcuts and you'll end up with a system that spans 5 different databases with some of the data on flat text files & excel spreadsheets. I know this because I've been there. It's a bit much to keep tally on everyone that wants to add some more "columns" in their own sql-system. If you make it too hard on the users, the users will stick their data anywhere to saves them a bit of time.

  • OSS, need one part (Score:2, Insightful)

    by Tablizer ( 95088 )
    I've been kicking around building an OSS database utility to compete with the likes of Access and Toad. It would be based on PHP, SqLite, and ODBC. However, I cannot find a decent open-source JavaScript editable data-grid control. They tend to have one big flaw or another. Maybe in another year such will finally mature. Data-grids are a must for such a util.
  • It seems as though you're looking for some type of development platform, not necessarily a database. Fact is, that's why a lot of people use Access for small stuff. It essentially allows them to quickly develop an "application" (from the user's viewpoint). Yeah, there's good and bad to that.

    This seems to be more of a policy/management issue than a technology issue. If people even think for a moment that what they want may one day be used over the net or by more than one or two people, they should be cont

  • Axis (Score:2)

    by vandan ( 151516 )
    See my collection of Perl libraries for just such an occasion:
    http://entropy.homelinux.org/axis_not_evil [homelinux.org]

    • Re:Axis (Score:5, Interesting)

      by vandan ( 151516 ) on Thursday June 15, 2006 @12:34AM (#15537749) Homepage
      Sorry. I suppose I could have elaborated a little further.

      Axis is a collection of 3 projects:

      - Gtk2::Ex::DBI ( forms )
      - Gtk2::Ex::Datasheet ( datasheets )
      - PDF::ReportWriter ( reports )

      They're all cross-platform ( heavyily tested under Linux and Windows 2000 ) and open-source.

      The basic idea is that you create your GUI in Glade ( ie Gtk2 ). You then create a Gtk2::Ex::DBI object, pass it your Glade XML file, and it will connect to the table you specify, and 'bind' all the widgets in your Glade XML file with a name that matches a fieldname in the table.

      The datasheet module is similar, but instead of creating a GUI and laying out widgets and such, everything goes into a treeview ( datasheet ).

      PDF::ReportWriter makes high-quality reports from XML report definitions. It supports unlimited grouping, group functions such as sum, count, etc, intelligent page breaking, page headers & footers, and a WHOLE lot more.

      There are plentiful screenshots on the website. All modules are under active development ( ie right now ). All feature requests, bug reports and patches welcome. Check it out :)

      http://entropy.homelinux.org/axis_not_evil [homelinux.org]
      • Excuse me but this seems terribly complicated. I know very little about databases and have wanted to get into it for the longuest time. Anyone can recommand some practical tutorial on how to put together quick php pages interfacing with some easy to setup SQL flavor ? Most of the tutorials I've seen are usually about pure SQL stuff.
        • No, it's actually quite simple. Look at the demo code on the website. You need about 20 lines of code. If you think you're going to get a fully functioning database app in PHP in 20 lines of code, then you are seriously mistaken.
          • OK, so you can write a database app in 20 lines of code. Now, how difficult is it for you to figure out, as a newbie, what those 20 lines should be? Most of the gee-whiz technologies I've seen utterly fail the "simple to learn" test. PHP is great because it is very easy to learn (which is why it's used so often, even though it is subpar in almost every other respect).
            • Um. There is demo code on the website. Perhaps if you looked at it, or at the demo application in the download section, and you applied some intelligence to the task, and perhaps even emailed me and asked for help, you'd be able to figure it out. Come on, did you really look, or what?
              • I think this exchange shows why these tools need to be 'dumbed-down' to a level so that people can get started without reading any documentation... It seems that no one reads any documentation anymore.

                Using gladexml and perl is a great idea. All it needs is a 'wizard' to install everything required on to a computer, and a 'wizard' to start a project.

                Then, the people who would normally use "Excel As A Database" may be able to understand and use it. That may save countless hours and frustration and cost due
    • A large percentage of corporate users - those most likely to be interested in your project in the first place - are probably unamused at the politics evident in your only screenshot [homelinux.org]. Yes, it's lighthearted. Yes, it's only cosmetic. But yes, it instantly reeks of "hippy in a basement".

      Your project may be absolutely brilliant, but don't go out of your way to antagonize your potential customers even if your friends also think it's funny.

  • For 200 users, with user-level security, you just need to find a tech willing to actually spend the time to make Access work. 2007 has plenty of additional gizmos, incluing a new "attachment" data type to, well, store those documetns you can't really store in Access.

    (You can store Images in Access. You use the "image" file type.)

    Now, if you just want to upgrade their database, the SINGLE CHEAPEST thing you can do is setup SQL Server 2005 Express. Access can upgrade itself to use the server (Use the "SQL Database Engine" if you're version-shy), and you gain all of those things that you don't have now.

  • Doesn't matter (Score:3, Insightful)

    by ScuzzMonkey ( 208981 ) on Thursday June 15, 2006 @01:28AM (#15537951) Homepage
    Pick whatever database backend you like; big, centrally managed, scalable, as complex as you like. IT manages it; handles the schema and maintenance, necessary stored procedures. A professional data architect in the IT department has final say on the architecture, but works with the requesting parties to ensure that it can fill their data needs. If necessary, views or similar can be constructed and made available on top of the actual data structure to make it easier for the non-programmers to interact with. You then expose, with appropriately restricted permissions, the database server to all these people with their small pet database projects. You know that most of them are going to be looking at most of the same basic table structure--they need names, phone numbers, whatever. It's a decent bet, since they're in the same company, that they're actually going to be storing the same data, no less. Let them at it--give 'em ODBC connections and turn 'em loose.

    They do the work; you give some input and assistance, but don't turn any of them into full-blown development projects. All you have to do is manage the backend. They get to scratch their itch, you get to look helpful and enabling, and no one gets sucked into big, expensive tools or projects.
  • Your solution is right under your nose and it's called SharePoint. Not only does it have the functionality to store data in all kinds of structured form (since it has a SQL backend), it also has the ability to search inside MS Office and PDF documents.

    But don't feel bad - our company did the same thing that you're company probably did when it rolled out SharePoint - we didn't assign admins or permissions correctly, train people, or provide design guidance which caused the project to be a failure.

    So we bough
  • There's no point fighting with Access to try to make it do something it wasn't designed to do, namely large-scale multiuser access to a big database. What you want is an easy-to-use RAD tool with the fastest native database in existence, namely Visual FoxPro 9. It will handle hundreds of users accessing GB's of data with no problem at all. Yes, that's right, FoxPro, and despite VB people saying since 1994 that Fox is dead, the next version will be out soon and it's supported until 2015. Unlike VB6. Also,
    • You're freakin' high. VFP is a hugely broken piece of junk that freaks out with more than a few gigs of data and more than a couple tens of users accessing it at once. Since its "database" is made of flat text files that you share with each and every user via a fileserver, forget accessing it over anything less than a 100Mbit LAN.

      My company's spending a lot of time and money migrating away from that hideous trashheap. Gentle readers, I assure you this: the only people who would ever actually recommend

  • Have you looked at Glom?

    http://www.glom.org/wiki/index.php?title=Main_Page [glom.org]

    From the front page...

    What you need, without the nonsense. With Glom you can design database systems - the database and the user interface. * Glom has high-level features such as relationships, lookups, related fields, related records, calculated fields, drop-down choices, searching, reports, users and groups. * Glom keeps things simple. It has Numeric, Text, Date, Time, Boolean, and Image field types. * Glom

  • I haven't used it, but there's bunch of new stuff [iponet.net] in Access 2007 that might be of interest, including an attachment datatype (documents, images, etc...), improved SharePoint integration (access control, workflow, offline lists). of course, you can pass through to a DBMS if Jet become a limiting factor...

  • ZOPE is all you need ... (Score:3, Informative)

    by be_kul ( 718053 ) on Thursday June 15, 2006 @06:18AM (#15538571)
    and - for instance - Plone, too: It
    - runs on almost everything (Windows, Mac OSX, Linux, *BSD - from Servers to Laptops),
    - is very easy to set up and maintain, - has an easy-to-understand web-based user interface,
    - has a simple but powerful user management
    - can store data in almost any SQL database, but
    - comes with its own, very powerful object-oriented DB (ZODB).
    Especially the last point makes it appear "naturally" to many users: They can store data as they are used to do in their filesystem inside folders, documents etc. There is a LOT of additional, easy-to-use plug-ins (called "products") that allow, for instance, to put files onto the filesystem through-the-web -- and: all is very easily scriptable with Python.
    So: Welcome to the Zope/Plone Community ;-)

    • The original poster was considering sharepoint but found it lacking. I would totally agree that plone might be just what the original poster is looking for. It is easy to integrate your own apps into this CMS by writing your own document types (called archetypes [plone.org]) and skinning them using TAL [zope.org]. Aggregate, navigation, or reporting pages can be easily cooked up with a little python script and skinned by TAL.

  • Sounds Like You Need a CMS (Score:3, Insightful)

    by John_Booty ( 149925 ) <johnbooty@booty p r o j e c t . o rg> on Thursday June 15, 2006 @06:54AM (#15538627) Homepage

    Sounds like you need a content management system, not just a database. Your users basically seem to wish for a way to share project-related materials. I see you've already considered that...

    We have tried Sharepoint with some success but that is pretty limited too

    ...so I'd definitely be interested to hear what limitations you ran into there. It's highly possible that some of the open CMS systems (Drupal, etc) could offer you what Sharepoint doesn't, but it's hard to say without knowing exactly what parts of Sharepoint you found limiting for your needs.

    You might also consider a hosted collaboration tool such as Basecamp [basecamphq.com]. I haven't used it myself but it has quite a few fans. It's probably more limited (and certainly less extensible) than software like Drupal but the ease of administration (since it's hosted) and easy accessibility (since it's not on your LAN, it's on the 'net) could compensate. Then again, if you're the IT guy... perhaps you don't want a zero-administation solution for job security's sake. :)

  • Take a look at Alphora [alphora.com.] Dataphor. While it is not an end-user tool, it has the potential to lower your development costs so much you will be able to actually serve your users.

  • Any type of data, trivial to develop web based applications which access an SQL backend, or which don't. Scales easily to hundreds of users, has a very powerful built in security and authentication system.
  • http://www.quickbase.com/ [quickbase.com] ... web-based, hosted by intuit, multi-user, permissions, file attachments, easy gui tools for editing the db, customizable interface, http, java, perl, vb, ruby apis, xml in/out.

    there are also a few others: http://www.dabbledb.com/ [dabbledb.com] http://www.eunifydb.net/ [eunifydb.net]

    http://oakleafblog.blogspot.com/2006/03/dabble-db- new-look-in-web-databases.html [blogspot.com]
  • There are lots of suggestions here about what product to use since that is what the question asked. But I don't think that is really the correct question. You end up either with easy technology that is not flexable enough for their needs, or powerfull technology that is too hard for the non-tech users to get a handle on. Either way, they are not going to get what they want out of it.

    The correct question should have been: How can we empower our users to get the functionality they want without going into the

  • Access - SQL migration (Score:3, Informative)

    by iamr00t ( 453048 ) on Thursday June 15, 2006 @08:58AM (#15539054) Journal
    Migrating from Access to SQL would be logical for you. Clients keep using Access and its forms to access the data, so they keep the application that they developed, and you get managebility, proper multi-user and access permissions.
    It will be almost transparent for users.
  • I am DEFINITELY not a Windows person, but I seem to recall setting up an ODBC connector to let Access (or some other common Windows app) see into our PostgreSQL database. Other than setting up the connection the change was entirely transparent to the user.

    Is that the case? If so, would this solve your immediate problem since the users could continue to use Access for smaller projects that don't warrant a full web-based solution? At least the data will be centralized and routinely backed up.
  • Create mySQL databases and teach them how to use Excel and Access as the front end.
  • Rekall
    and
    Bond (building object network databases) are two products that might interest you.
    Alpha V5 is not open source, but it can certainly compete with filemaker in terms of scalability since version 7(it can use, among other things, mysql directly)

    However, why doesn't the poster just start over, covering exactly what database/application needs are there, and start from there. Very few business environment develop continuously(except software developers/service providers), and those have people whose job
  • Setup a copy of an Access ADP file on a everyone's machine. Have the ADP file point at a database on your SQL Server and your golden. To them they just using an Access database minus many of the limitations in Access.

    If security is an issue, then make a custom ADP for each user with thier own user ID's.

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close