<div dir="ltr">If you couldn't log in, how do you know it does some of what you need?<div><br></div><div>It has a user and a password filled in, just click the "Enter" button</div><div><br></div><div>Amichai.<br>
<br><div class="gmail_quote">On Sat, Dec 4, 2010 at 16:49, Eyal Rozenberg <span dir="ltr"><<a href="mailto:eyalroz@technion.ac.il">eyalroz@technion.ac.il</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Amichai:<br>
<br>
I couldn't login at <a href="http://demo.geeex.net" target="_blank">http://demo.geeex.net</a>, 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.)<br>
<br>
Guy:<br>
<br>
Thanks for the 2c+p :-)<br>
<br>
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).<br>
<br>
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.<br>
<br>
2. Yes, I did verify that. But the server will not be more than a souped-up single PC.<br>
<br>
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.<br>
<br>
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.<br>
<font color="#888888">
<br>
Eyal</font><div><div></div><div class="h5"><br>
<br>
><br>
> as a non-expert in this area, i will try to give you two cents and a<br>
> penny ;)<br>
><br>
> 1. regarding scaling the existing solution - i guess that switching the<br>
> back-end to using SQL server will make it scale better. further, it<br>
> might be possible to make a crude test of this without changing the<br>
> entire application - i think i remember that access can use SQL server<br>
> as a backend. there used to be a free version of SQL server (that was<br>
> limited to 10 users) - which may be used in such a "proof of concept"<br>
> test. it used to be called MSDE. these days it is simply the "express<br>
> edition" of sql server 2005 or sql server 2008. if you live with the<br>
> limitations it imposes - you might be able to use the free version also<br>
> in production:<br>
><br>
> <a href="http://www.microsoft.com/express/Database/" target="_blank">http://www.microsoft.com/express/Database/</a><br>
><br>
> 2. did you verify that you don't need to simply upgrade the server<br>
> hardware? or do you also see the slow down on the client machines?<br>
><br>
> 3. i imagine that if you build such a thing today, making it web-based<br>
> will make more sense then writing a full-fledged application client.<br>
> especially if you'll use a linux back-end - since you'll want the<br>
> clients to work on windows. with today's technology, web applications<br>
> can give you a good frontend (with use of javascript and ajax) to show<br>
> data records (e.g. look at google's online spreadsheet application).<br>
> of-course, it'll be a good idea to define the desired interface first,<br>
> and see how much data you want to display at any given time, and make a<br>
> small proof of concept to see that the javascript code in the browser<br>
> handles it well (javascript is somewhat slow - and i'm not sure if it'll<br>
> work to show thousands of records on a single screen - so you need to<br>
> figure out if you need to be able to do this on the client - or whether<br>
> viewing by "screens" (show first 100, show next 100, etc.) will be good<br>
> for you when showing query results.<br>
><br>
> 4. i would suggest that you subscribe to the linux-il mailing list -<br>
> there are many more people there, and in particular - people that work<br>
> with LAMP for their living - they are likely to be able to give you<br>
> better and more specific advice:<br>
><br>
> <a href="http://www.hamakor.org.il/mailing-lists/linux-il.html" target="_blank">http://www.hamakor.org.il/mailing-lists/linux-il.html</a><br>
><br>
> keep in mind that some of them are consultants and developers that<br>
> provide the development services you are looking for - so they can help<br>
> you better (and on the other hand - they may be biased towards their<br>
> preferred solutions).<br>
><br>
> --guy<br></div></div><div><div></div><div class="h5">
_______________________________________________<br>
Haifux mailing list<br>
<a href="mailto:Haifux@haifux.org" target="_blank">Haifux@haifux.org</a><br>
<a href="http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux" target="_blank">http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux</a><br>
</div></div></blockquote></div><br>
</div></div>