> Now I also wondered whether there was such a thing as a gui front end > to this backend type programme. Anyone got any knowledge ?
They probably exist. StarOffice has a data wizard kinda like Access in the front end -- in other words, the interface works more or less like Access, For a backend, there are a variety of possibilities. It seems though, that the 'right' way to do it is to use Web-based forms to do the data entry or whatever, and have CGI scripts to do the actual insertions or queries or whatever. > Also, I would like to understand, what if any is the difference > between using a spreadsheet programme and using a database programme. They both can be used for the same thing. Obviously, some things are better suited for a database. For a lot of people, spreadsheets are easier, because yuo don't need to define any of the relationships betweeen data - just making column headers is sufficient, and putting the necessary formulas for the other columns and so forth. And as a plus, the reporting is in the sheet itself - no need to use an external app to produce nice looking reports from the database. This alos presents problems: in a spreadsheet, if you want to change the report, you change the spreadsheet - and change it back, or make a new sheet from the data in the old one. With a database, you just create a different report (or view). Spreadsheets are better if there's mostly computation going on, less so if there's going to be a lot of lookups/finds and so forth. A real-world expample: one of my main tasks at a temporary position I had ca. 18 months ago was to set up reporting and tracking methods for a 'database' of parts. I got some of the original data from our internal database, some from outside sources (f.e., outstanding parts reports over the Net) and combined all this in a way that was useful for other engineers and management. My platform was a P-100 with 64 emgs of RAM, running Windows 98 probably, and Excel. Plus, the "real-world" databases I have used at work would likely be way too cumbersome as a spreadsheet, or series of related spreadsheets. But a sheet would make some things easier if just a subset of the data were available. Like if you just have a simple list of names/addressses/etc., you really don't need to go out and get Oracle :). The data overall ended up at many megabytes worth - it was probably 5 megs or so xls file. Inside, there were quite a few lookups (i.e.., =vlookup() ) to external tables (i.e., spreadsheets) to derive things like part name-part number translation, price info, availability, return status and so forth. Of course, these 'forests' of vlookups and so sort made working with the spreadsheet extremely cumbersome at times, and setting up a database, especially given the 2000+ vlookup formulas in the sheet, might have made better sense. There were several times when the machine simply swapped itself for hours, and I couldn't do anything. I did manage to find out that Excel thought the file much bigger than it was originally (I had highlighted some rows and such) -- which no doubt contributed to the heavy memory use, and might be something worth looking into in your kspread issue. > different ways. In the spreadsheet programmes it would seem , the > programme and the data are all loaded into memory, perhaps database Correct. All the spreadsheet needs to fit within memory. VM does exist, of course (back in the DOS days, I evaluated some VM extras on 1-2-3 and the like) but as someone more knowledgeable than I at the time said, '' spreadsheets have poor locality of reference'' which loosely means that a formula in cell AE2156 might reference one in cell G23, and the poor box has to swap parts of the sheet back in and out to resolve everything. > John Richard Smith > [EMAIL PROTECTED]
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
