Christian wrote: > Would this break the formulas, etc? I have not tried this, because there
It doesn't matter what you do those formulas will be broken. You can always rewrite them within the SQL statements that extract the data. > Right, that is several hours of work, and then the problem remains that this > solution needs to be adopted by all of the educators (teachers and staff) They aren't educators. Educators would have chosen the right tool for the job. In terms of convincing them to adopt a LAMP solution, I'd toss it up on the school Intranet, and let them play with it for a few days. You may need to spend a couple of days observing how data is filled in, to create ergonomic data input screens. Any hardware/software that the school uses to automate attendance taking, etc, might require modifications for import into the database. > These educators are already somewhat suspicious of FOSS, simply because they > are not familiar with it, Then they will hate the LAMP solution. And positively loathe it when they discover that the same UI will be used for all databases within the school. And if the LAMP is on the Internet, their fears are magnified, because it means that parents will be able to determine more quickly, and easier than ever before, just how their kids are not doing in school. >and they think that it will require them to make major changes in their lives. It might. You are providing them with a practical demonstration that quality can be inexpensive, and junk can be extremely expensive. > That would be an obvious solution except, again, for institutional lethargy. Ask them how much they are willing to pay in fines, because their school will fail a BSA software audit. > They have a standardized template that they use, and the teachers are all > expected to report in that format. The report is simply data output. That won't affect data input, or storage. All it affects is the creation of the script to produce the output. Properly done, you won't be able to tell the difference between the spreadsheet, and the LAMP solution, when printed out. > And there are references back and forth among the several tabs, so breaking > it out would, again, be a lot of work with not much time left. It depends upon what those cross-references are. (Well, I know what they are. The artifacts of somebody who thinks that the only tool used to build an Egyptian Pyramid was a a number ten spanner.) If that data has a 1-1 correlation, then it can go in a flat field database. Otherwise it needs to be in a relational database. In either instance, MySQl can be used. Probably overkill for flat field databases, but the resulting data integrity more than offsets the associated cost. > And, actually, I am assuming that there are advanced formulas and macros, > because OOo does not accurately produce the sheet. Formulas can be rewritten in other languages. If the formulas, or cells break in OOo, odds are they are also broken in MSO. Noop wrote: >1. Check to see if the spreadsheet is shared. Meaning that teachers can edit etc., at the same time. You won't be able to do this with OOo (at present). This is why I suggest a LAMP solution. It allows for things that neither OOo nor MSO can do. > Technophobe staff; your greatest problem will be the principal. You must first convince her to support a trial. >Ironically enough I am responding to you using a salvaged public school (from the greater San Francisco Bay Area) computer that had been sitting in a recycle bin for nearly 1 year. This is yet another reason for going with a LAMP solution. Those "recycle" bins would become "spare parts" bins. LAMP will be viable for at least another decade, if not longer. The biggest issue with a system from 1995 using a LAMP solution is drivers for the ethernet card. They are probably available for Linux, but not Windows. > you won't accomplish much unless you can convince the top staff that the > school's business and administrative practices need to change, and that the > change is for the better. +1 >Spreadsheets and/or databases can easily be changed as long as the basic data can be exported/imported/copied etc. +1 >of the regulars on this list could take the 6Mb Excel spreadsheet and provide a reasonable OOo replacement (Calc or Base). Could? Probably. Willing to? Probably not --- especially when the solution encourages using the wrong tool for the wrong job. >are placing too much emphasis on the ability to use existing data in it's original environment vs the ability to use the data in a new environment. I doubt that that is Christian, as much as it is the technophobe. The vast majority of people have the mistaken idea that if data can be displayed in a manner that is independent of how it is stored. (Web designers go further, in that their demonstrably false but fundamental axiom is that electronic data is identical to hard copy print, and they point blank refuse to believe that there are major, fundamental differences between the two.) > the 'technical' box, and instead build a defense for the longer term advantages of using FOSS/OOo/etc at the school. +1 >I'd also suggest that you have a look at StarOffice. OOo is basically the free version of SO, and Sun have added macro & templates that assist in making a MS to SO transition. It's free to educational institutions, But are those MSO to SO transition programs free to educational institutions? Ian wrote: > It would be far better for FOSS to get the database done for all schools rather than just solve an immediate problem with a sticking plaster solution in one school. +1 I'd suggest LAMP rather than the database alone. > But it is more work initially and time you might well not have :-(. It takes as long to create a viable solution as one that is not viable. If one doesn't have time to create a non-viable solution now, when when will one have time to create a viable solution? xan jonathon -- OOo can not correct for incompetence in creating documents from MSO. Furthermore,OOo can not compensate for the defective and flawed security measures used by Microsoft. As such, before using this product for exams that require faulty and defective software, ensure that you will not be unjustly penalized for the incompetence of the organization that requires the use of software that is known to be flawed, defective, bug-ridden, and fails to meet ISO file format standards. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
