[kwlug-disc] What's the simple next level beyond OpenOffice Base?

[unsolicited]

Khalid Baheyeldin wrote, On 11/27/2010 10:19 AM:
> On Sat, Nov 27, 2010 at 1:54 AM, unsolicited <unsolicited at swiz.ca 
> <mailto:unsolicited at swiz.ca>> wrote:
> 
>         Since you are already using spreadsheets but consistency is the
>         issue,
>         why not use Google Documents, which has hosted spreadsheets, that
>         people can collaborate on simultaneously.
> 
> 
>     I've tested Google Docs. There is no data consistency / validation
>     facilities within it. It just hasn't gotten that far, yet.
> 
>         And you can also upload your existing Open Office sheets in it,
>         so setup
>         is quick.
> 
> 
>     Yes. But, for example, I uploaded to it with some cells data
>     validated. Then brought it right back - the data validation was
>     gone. I tried it both ways - they have 2. One that facilitates
>     online editing as well, the other where it is merely storage. I did
>     not expect the storage to change the file, but it did.
> 
>     Google Docs won't do here.
> 
> 
> It seems that you already have logic inside your spreadsheet, and that gets
> lost when you upload the sheet. You may be using OpenOffice specific
> validation or macros.

And your point is?

i.e. That's the nature of the beast.

> This is the start of "code sprawl". Instead of spreadsheets being just 
> data,
> they contain code (business logic) in them, and in effect, you have an
> "application".

Yep, that's the nature of the beast. People do what they can, to the 
extent that they can, with the tool they have in front of them.

> An application is something you have to maintain for many years to come:
> debug, modify, extend, ...etc. They have a life of their own, and require
> time and effort to continue to exist. Application development is not a one
> time thing. It is an on going effort.

Yes. Nature of the beast. Been doing this stuff for almost 30 years. 
I knew what I was signing up for when I volunteered to help out.

> So, whatever you decide to replace that with, take this into account. For
> better or for worse, you have an application that needs to be maintained
> for the foreseeable future.

Yep.

> All the online hosted databases look appealing at first, but with such 
> small
> companies, I am uncomfortable with longevity and lock in. Your code
> AND data are at the mercy of that company. You can spend countless hours
> developing on their platform, and if they raise their rates, or go 
> under, you
> are done. It is all wasted effort, AND your data is gone. There is no 
> migration
> path.

Yep. Thus my question, and the purpose of posting, to the group.

> At least with Google, your data is still downloadable, and they will not 
> shut
> down for some time.

Arguably, Google fits your prior paragraph. Nothing says the data will 
be retrievable in a suitable format in the future. [Don't know HOW 
many conversion programs I've had to write to take in a dBase file 
format and convert to whatever internal format was in use at the time. 
Even wrote a QNX dBase file reader/writer. (No indexing.) (-: ]

> Consider something that is LAMP (e.g. a PHP or Python application with a
>  MySQL or PostgreSQL backend). You can host it internally (on premises,
> on your own hardware) or externally ($20 a month maybe?).

As said in initial posting - no server possible, in the foreseeable 
future.

> At least it is all based on open source stuff that you can download and
> run locally, and the data format is just columns and rows in a database,
> that you can convert/manipulate using a myriad of tools, should the need
> arises.

Yes, agreed. Which is why I was willing to even post the question, 
involving these Windows users, to a LUG.

> The Glom path seems like a good one too. If you don't mind sticking with
> their data format for the future.

In poking around, it does seem like that is inevitable. If, by data 
format, you are referring to the 'code' that surrounds the data 
itself. e.g. An OpenOffice form / document / spreadsheet / database. 
Move to anything else, and the wheel will have to be reinvented in 
that new environment. And environments are going to inevitably change, 
over time. Particularly as each new kid on the block appears.

As I indicated, the significant value of spreadsheets, at the moment, 
is the users can work with it to explore and discover wherever it is 
they are trying to go. When that settles down, the system requirements 
will also become more complete. In essence, they are prototyping, and 
that's no bad thing. At least, with this mechanism, they are able to, 
on their own. Further, by establishing some data validation rules, 
they inherently refine those requirements.

Right now, I'm not entirely convinced they should move beyond 
spreadsheets. The back end data extraction requirements are not well 
defined / known / understood at the moment - it is still evolving. 
Largely I'm not convince because I think they will need to be able to 
work against any database moved to, in a spreadsheet, to explore, 
mash, mangle, discover, etc.  Currently, OpenOffice, even against 
Base, is just broken when connecting to things via data source / calc. 
e.g. Within the data source view, one can directly edit the database - 
there goes your data validation, formatting, input controls. Multiple 
ways of inputting a record to a database would seem to be a very bad 
thing here. I have hints, though, that a Base database connecting to 
an external server/file (e.g. MySQL or .dbf) has the same issues. I 
may have to play - which is part of the point of my post: I can 
download MySQL, but there is no IDE / front end for application 
development surrounding it - thus the part of my post about what FOSS 
is out there to use from an IDE perspective.

Rekall seems not in the cards - I can see no mention of rekallrevealed 
since 2005, and the rekallrevealed.org has expired. rekallrevealed 
being the free / community edition of rekall. Pity as it seems the 
most flexible mention so far.

One of Raul's other mentions, and thank you again for the links Raul, 
leads to a Postgres only / Delphi / Interbase reference taking one to 
Lazarus. http://www.lazarus.freepascal.org/index.php/page,7.html. I 
may be confusing Lazarus with free Clipper apps at this point - all 
the web pages are starting to blur together.

Glom seems interesting, but it Postgres. Which is to say, back to a 
server. And what hadn't occurred to me with my initial post is that 
moving to anything other than a spreadsheet is going to involve either 
slinging multiple files all around, and probably re-instantiating the 
files within the local database, wherever they land. Not sure that 
that's a good thing / somewhere I want to go. Intuitively, I didn't 
expect that, assuming a MySQL back end, but I now suspect that that's 
my inexperience coming out - Postgres, MySQL, or anything else, it's 
going to be about the same.

And, upon further reflection, perhaps a server is possible. Since 
anything like MySQL, Postgres, or whatever, is likely accessed by a 
single port, a viable solution may be to have the data and database in 
one location, and have people ssh in and port redirect. Slinging app 
files and spreadsheets is still in the mix, but at least the data 
isn't moving all about.

Thanks everyone, I do appreciate the continued comments. Part of my 
point in posting was to expose the other considerations coming in to 
play with what is being contemplated. It's not just a spreadsheet, or 
a database, but it's database maintenance, an IDE, app deployment, and 
probably many other things. By posting I'm able to consider more 
things up front, reducing the number of continual rude discoveries, 
and backtracking from dead ends, along the way.