By the sounds of it, the OP wants a spreadsheet app, that isn't a spreadsheet app, acts like a database, but isn't quite a database, looks simple to use, but provide editable information in a reasonable format.
To bring up a point about Google that RSmith brought up, Google Docs has a spreadsheet app that has zero install, accessible by many (If you want) and available from anywhere provided an internet connection is available, and allows you to edit, search, sort, filter, and all the other bells and whistles other spreadsheet and database applications have. Mind you linking an external data requester application might be a bit of a PITA (If that is a requirement) might start throwing additional complexities into the mix. Since the LAMP setup is available, there are other spreadsheet type applications that allow you to move from Google Docs to in-house. Off the top of my head I can't think of the names I've used in the past (I write databases, not spreadsheets) but they are out there, free for all, just short of public domain (MIT maybe?), and in a 'download-extract-run-configure' format usually, which is GREAT with a LAMP setup. The other option is to go ground up with PHP and some very basic AJAX calls, but even then, you'd need SOME kind of management. How many rows to display, how many columns to display, do we add rows, remove rows, what field is what cast, validation requirements, data storage considerations, data VOLUME considerations, who accesses the data, what is read only and who/what can write to the table, are we talking one database, one table, one user, or, many databases, many tables, many users, does encryption come into play and if so at what level? Some kind of management HAS to happen, like it or not. And if basic management comes into play, you might as well stick with something that already exists (Google Docs, OpenOffice, LibreOffice, Excel, Notepad). >From a mile high view, O.P., from a ground up build of an application perspective, what you're requesting LOOKS simple, but there are a TONNE of things to take into consideration that must happen in the back end. Even with forgetting about security, validation, and accessibility. That stuff just icing on the cake. Take this example; 5x5 text field form. That is 25 fields. Each field has to have a unique identifier. Using the Spreadsheet format, A1:E5 is the range of cells. Things to consider - Is this a field to be calculated? - Is this actually a number? - Does the cell reference something else? Code has to be written for that. Two months later, you realize that 25 cells is just not enough info. So now we're looking at more rows, more columns, more data. Is this going to require a database rewrite? Cells need to rely and reference other cells? Forget the back end, how do we draw the UI? Now we're throwing tabs into the mix? So now I have to deal with something in the range of AA1:RZ10? How am I going to get a web page to throw 4420 cells on the screen AND make it somewhat serviceable? (26*10*17=4420) Two months later, you want to give read only access to someone else to view your 4420 cells. User authentication has to come into play. oAuth, or simple user/password? We talking encryption at authentication, or for authentication AND showing the UI? On Tue, Jun 3, 2014 at 1:48 PM, RSmith <rsm...@rsweb.co.za> wrote: > A very simple to use interface can be programmed with C# maybe which I am > sure would have pre-made data grids. The dev system I use for Linux which > definitely has all the bells and whistles and you can probably hack > together the exact thing you mention in about 30 minutes is called Lazarus > which is a kind of "Delphi for Linux" type thing which support most DBs > natively (or easily addable) with grids and data connections/adaptors, but > if I were you would go for a dev system I know well. Is there one you know > well? A simple Google on it might find us some DB Grid type controls > already made by someone (probably for use in some clever DB manager, but > which you can re-appropriate in a more simplistic app). Kevin's Gtk > suggestion sounds like a plan that can be both relatively easy to implement > /and/ easy to use, if you are familiar with that dev system and the > intended users are not complete ignoramii. > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
