[Haifux] FOSS alternatives to an Access-based organizational software solution

[Amichai Rotman]

If you couldn't log in, how do you know it does some of what you need?

It has a user and a password filled in, just click the "Enter" button

Amichai.

On Sat, Dec 4, 2010 at 16:49, Eyal Rozenberg <eyalroz at technion.ac.il> wrote:

> Amichai:
>
> I couldn't login at http://demo.geeex.net, I need a username and a
> password... from the looks of it, it does some of what we need, not
> necessarily the way we need it. It may or may not be a good departure point
> from which a developer might start coding. (Assuming it's free enough to
> modify.)
>
> Guy:
>
> Thanks for the 2c+p :-)
>
> I'll start by making an important point, which is that I'm an elected
> official whose time is devoted to the political work of the organization,
> not to technical issues. In fact, I don't have admin privileges anywhere.
> And the person supporting our current app has low availability unless we
> contract him specifically for some task. And our administrative manager's
> automatic answer about anything tech-related is "No, let's not change
> anything, we have too much trouble on our hands as it is" (which is right
> about half the time unfortunately).
>
> 1. The scaling issue is a significant problem but not the critical one at
> this point. We need a sort of a rewrite for other basic design reasons. But
> it is indeed possible that an Access rewrite using a real DB as a backend
> might work.
>
> 2. Yes, I did verify that. But the server will not be more than a souped-up
> single PC.
>
> 3. So you're not resolving the "web-based or not" dilemma for me... I will
> say that there's no specific need for a web-based front-end. The system only
> needs to be accessed from our computers, not from anywhere else. In fact,
> even a multi-platform frontend is not an absolute requirement. A Windows
> client/front-end with a DB-only back-end running on, well, anything, may be
> enough at this point. Of course, being multi-platform is a nice plus. About
> numbers of records - for daily tasks you don't need to display a huge amout
> of data on-screen, but I do need things like type-ahead find, and sometime
> you do have a large number of records with which you need to do something,
> it just doesn't involve displaying them.
>
> 4. Will try there, thanks. Biased is quite alright, I'm not trying for the
> theoretically optimal solution, I'd like to find someone who can offer me a
> solution which works, is not overly expensive to develop/set-up, and can be
> supported.
>
> Eyal
>
>
> >
> > as a non-expert in this area, i will try to give you two cents and a
> > penny ;)
> >
> > 1. regarding scaling the existing solution - i guess that switching the
> > back-end to using SQL server will make it scale better. further, it
> > might be possible to make a crude test of this without changing the
> > entire application - i think i remember that access can use SQL server
> > as a backend. there used to be a free version of SQL server (that was
> > limited to 10 users) - which may be used in such a "proof of concept"
> > test. it used to be called MSDE. these days it is simply the "express
> > edition" of sql server 2005 or sql server 2008. if you live with the
> > limitations it imposes - you might be able to use the free version also
> > in production:
> >
> > http://www.microsoft.com/express/Database/
> >
> > 2. did you verify that you don't need to simply upgrade the server
> > hardware? or do you also see the slow down on the client machines?
> >
> > 3. i imagine that if you build such a thing today, making it web-based
> > will make more sense then writing a full-fledged application client.
> > especially if you'll use a linux back-end - since you'll want the
> > clients to work on windows. with today's technology, web applications
> > can give you a good frontend (with use of javascript and ajax) to show
> > data records (e.g. look at google's online spreadsheet application).
> > of-course, it'll be a good idea to define the desired interface first,
> > and see how much data you want to display at any given time, and make a
> > small proof of concept to see that the javascript code in the browser
> > handles it well (javascript is somewhat slow - and i'm not sure if it'll
> > work to show thousands of records on a single screen - so you need to
> > figure out if you need to be able to do this on the client - or whether
> > viewing by "screens" (show first 100, show next 100, etc.) will be good
> > for you when showing query results.
> >
> > 4. i would suggest that you subscribe to the linux-il mailing list -
> > there are many more people there, and in particular - people that work
> > with LAMP for their living - they are likely to be able to give you
> > better and more specific advice:
> >
> > http://www.hamakor.org.il/mailing-lists/linux-il.html
> >
> > keep in mind that some of them are consultants and developers that
> > provide the development services you are looking for - so they can help
> > you better (and on the other hand - they may be biased towards their
> > preferred solutions).
> >
> > --guy
> _______________________________________________
> Haifux mailing list
> Haifux at haifux.org
> http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://haifux.org/pipermail/haifux/attachments/20101204/4b647f6c/attachment.html