For what it's worth, if your in a hurry, try our product, it's Free.
Basically, you launch our product, connect to your database and we'll spit
out fully functional VB.NET or C# data/business entities using your
database meta-data as the input. These objects (classes) do mostly
everything that you need to do in a typical application. The advice below
is good, and I would add one thing. How long will it (the application) be
around and how hard will it be to maintain.

anyway, see http://www.mygenerationsoftware.com if you're interested.

- Mike

> Here's my tuppence worth.........
>
> I come from an engineering background where you're taught that rigour is
> the
> most important feature of any development.  I find that all the
> interpreted
> environments tend not to be that great in this regard.  Also, I don't have
> an axe to grind when it comes to the "anything but Microsoft" prejudice
> that
> a lot of non-MS programmers seem to have.  So, I would say that you need
> to
> decide what it is you're actually developing and then select a tool that
> is
> going to achieve that result - here's some questions to ask yourself;
>
>  a) Am I developing a web application or just providing some dynmic
> content
>
>  b) Can I fix the deployment platform (Windows/Linux/Solaris)
>
>  c) How much time have I got to develop this
>
>  d) What level/quality of service do I need to provide
>
> There are lots of other questions but these are good ones to try and
> resolve
> straight off.
>
> Most of the applications I am involved in writing are multi-developer,
> corporate wide systems and as such, it's not practical to choose a toolset
> that isn't supported by a good vendor and a large user base.  This tends
> to
> narrow the choices down to commercial products like
> .NET/Java/Delphi/C/C++/VB - by commerical I'm talking about the
> Development
> Environments (IDE).
>
> Over the years I've come to realise that programming is much the same in
> any
> modern environment - same symantics, different syntax.  what really makes
> the difference for me is the development environment, I'm at the age where
> I
> can no longer bear the thought of using notepad/emacs/vi/vim as my
> development editor for the sake of spending a few quid on a proper tool
> for
> the job that has Intellisense, aut-formatting, syntax checking etc.
>
> With that in mind, your choice is further narrowed and my current absolute
> favourite is Java Servlets with JDBC using JetBrains IntelliJ.  Low cost,
> professional, high performance, good CV fodder, beautiful IDE.
> If your pockets are deeper and you're sticking with Windows then .NET and
> ADO is quite frankly the best possible way to go.
>
> Hey, you wanted an opinion............
>
> p.s. anyone using assembler in a web environment should be kept away from
> sharp objects for their own safety!!
>
>
>
>
> -----Original Message-----
> From: Eli Burke [mailto:[EMAIL PROTECTED]
> Sent: 07 March 2005 21:23
> To: sqlite-users@sqlite.org
> Subject: [sqlite] thoughts on a web-based front end to sqlite3 db?
>
>
> I've been working on a project using sqlite3 since last fall. At the time,
> I knew that it would need a web-based front-end eventually. I have a very
> small bit of experience with PHP, and I assumed that PHP would support
> sqlite3 sooner or later. Well, it's later, and as far as I know, PHP
> is still using the 2.x branch.
>
> So, I was wondering if any of the more opinionated among you would care
> to suggest an interface language. It'll be on a Linux box, presumably
> running apache although I'm open to alternatives. The app itself uses
> sqlite3 for scheduling jobs and storing job data, so the web interface
> only needs to be able to insert some data and do visualization
> (pretty standard stuff I think).
>
> Ease of learning is a plus as I need to get something basic up and
> running fairly fast. I've heard good things about Python in that respect.
> Does anyone have alternative suggestions, or if you agree that Python Is
> Good, would you suggest using APSW, pysqlite, or something else?
>
> Thanks,
> Eli
>
>
>
>


Reply via email to