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 <eyal...@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@haifux.org > http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux >
_______________________________________________ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux