Major data loss: Calc formatting numbers

[Gene Young]

Robert Holtzman wrote:

> On Mon, 6 Jul 2009, Gene Young wrote:
>
>> Richard Detwiler wrote:
>>>
>>> I'm a bit confused by the statement about how information on users
>>> shouldn't be stored in a spreadsheet, because it is so easy to
>>> corrupt the data.
>>>
>>> Does this suggest that the only information that should be put in a
>>> spreadsheet is data where it doesn't matter if it gets corrupted?
>>>
>>> If so, that would significantly reduce the usefulness of spreadsheets.
>>>
>>> I assume there is some key point that I'm missing, so please
>>> enlighten .... thanks.
>
>> Basically a database is for storing and retrieving information.  A
>> spreadsheet is primarily for performing calculations on data.  In
>> common usage, people have come to use spreadsheets to store
>> information because the learning curve is much shallower than learning
>> to work with a database.
>
> The answer you stated addresses why people tend to use spreadsheets to
> store data. What I would like to know is why you think information in a
> spreadsheet can be corrupted more easily than that in a data base. As
> the previous said: "I assume there is some key point that I'm missing,
> so please enlighten ...."
>

People do not generally protect data in a spreadsheet, so every time it
is opened by another user, there is the risk that that user might
accidentally (or deliberately) change something.  Perhaps they have
their own favorite formats they want to see the spread sheet in.  Maybe
they prefer everything in 14 point Albertus Medium.  They may apply a
style to the sheet that gives that appearance and inadvertantly change
some other format that isn't readily apparent until someone notices that
the wrong numbers are rounded inappropriately.  There are many scenarios
that are less than pleasant.

In a properly designed database that possibility is reduced.  Not
eliminated, but definitely reduced.

--
Gene Y.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Robin Laing]

Gene Young wrote:

> Richard Detwiler wrote:
>> Robin Laing wrote:
>>>
>>> I have used OOo since before it was OOo.  I have not lost data due to
>>> the software in any case.
>>>
>>> As for data in spreadsheets.  I don't agree with using information on
>>> users being stored in a spreadsheet.  It isn't what it was designed
>>> for.  It makes it to easy for a simple user error to make a mistake
>>> and corrupt the data.
>>>
>>
>> I'm a bit confused by the statement about how information on users
>> shouldn't be stored in a spreadsheet, because it is so easy to corrupt
>> the data.
>>
>> Does this suggest that the only information that should be put in a
>> spreadsheet is data where it doesn't matter if it gets corrupted?
>>
>> If so, that would significantly reduce the usefulness of spreadsheets.
>>
>> I assume there is some key point that I'm missing, so please enlighten
>> .... thanks.
>>
>>
> Basically a database is for storing and retrieving information.  A
> spreadsheet is primarily for performing calculations on data.  In common
> usage, people have come to use spreadsheets to store information because
> the learning curve is much shallower than learning to work with a database.

Also, a database can have fields, records and other areas locked to
protect data from user input or changes.  Spreadsheets can be sort of
locked but that isn't perfect either as I have seen so many times in my
work.

A find and replace in a spreadsheet can be very dangerous if used wrong.
  A find and replace in a database is much harder to do outside the
current open record.

Also, linking between data fields is much easier in a database.

I agree that most users know how to use a spreadsheet and have to learn
a data base program.  It is well worth the time to learn how to use a
database program for storing records like employee information.

--
Robin Laing


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Per-13]

Q) As for data in spreadsheets.  I don't agree with using information on users
> being stored in a spreadsheet.  It isn't what it was designed for.  It makes
> it to easy for a simple user error to make a mistake and corrupt the data.
>


A) That is what this organization does. They have pretty good reasons for
not using Base or Access. This is not the place to discuss their
strategies, however, rather how we can help them achieve the goals
that they have set for themselves.


An Q & A: The answer is from Dotan himself in an other mail here at the forum...


We all know that a database is made for, well, databases... but in this case it´s not suitable....

/( sorry Dotan if I took the liberty to give this answer, but.... can´t they read the mail you wrote earlier ???)    ;-) /


// Per


Robin Laing skrev:

> Gene Young wrote:
>> Richard Detwiler wrote:
>>> Robin Laing wrote:
>>>>
>>>> I have used OOo since before it was OOo.  I have not lost data due
>>>> to the software in any case.
>>>>
>>>> As for data in spreadsheets.  I don't agree with using information
>>>> on users being stored in a spreadsheet.  It isn't what it was
>>>> designed for.  It makes it to easy for a simple user error to make
>>>> a mistake and corrupt the data.
>>>>
>>>
>>> I'm a bit confused by the statement about how information on users
>>> shouldn't be stored in a spreadsheet, because it is so easy to
>>> corrupt the data.
>>>
>>> Does this suggest that the only information that should be put in a
>>> spreadsheet is data where it doesn't matter if it gets corrupted?
>>>
>>> If so, that would significantly reduce the usefulness of spreadsheets.
>>>
>>> I assume there is some key point that I'm missing, so please
>>> enlighten .... thanks.
>>>
>>>
>> Basically a database is for storing and retrieving information.  A
>> spreadsheet is primarily for performing calculations on data.  In
>> common usage, people have come to use spreadsheets to store
>> information because the learning curve is much shallower than
>> learning to work with a database.
>
> Also, a database can have fields, records and other areas locked to
> protect data from user input or changes.  Spreadsheets can be sort of
> locked but that isn't perfect either as I have seen so many times in
> my work.
>
> A find and replace in a spreadsheet can be very dangerous if used
> wrong.  A find and replace in a database is much harder to do outside
> the current open record.
>
> Also, linking between data fields is much easier in a database.
>
> I agree that most users know how to use a spreadsheet and have to
> learn a data base program.  It is well worth the time to learn how to
> use a database program for storing records like employee information.
>

[Gene Young]

Per wrote:

> Q) As for data in spreadsheets.  I don't agree with using information on
> users
>> being stored in a spreadsheet.  It isn't what it was designed for.  It
>> makes
>> it to easy for a simple user error to make a mistake and corrupt the
>> data.
>>
>
>
> A) That is what this organization does. They have pretty good reasons for
> not using Base or Access.

This is not the place to discuss their
> strategies, however,

Why not?  This is a users group and the question was asked by Richard
Detwiler as to why not to store data in a spreadsheet?  It might be
stretched that he hijacked the thread but it is pertinent to the
original problem and this forum is for users to help users.

rather how we can help them achieve the goals

> that they have set for themselves.
>
>
> An Q & A: The answer is from Dotan himself in an other mail here at the
> forum...
>
>
> We all know that a database is made for, well, databases... but in this
> case it´s not suitable....
>
> /( sorry Dotan if I took the liberty to give this answer, but.... can´t
> they read the mail you wrote earlier ???)    ;-) /
>

Can't you read the email you are quoting?  Do not be so quick to
criticize others.  We all understand that Dotan's hands are tied.  We
were not suggesting that he force his friends to use Base.  Merely
discussing the pros and cons for someone who asked.

>
> // Per
>
>
> Robin Laing skrev:
>> Gene Young wrote:
>>> Richard Detwiler wrote:
>>>> Robin Laing wrote:
>>>>>
>>>>> I have used OOo since before it was OOo.  I have not lost data due
>>>>> to the software in any case.
>>>>>
>>>>> As for data in spreadsheets.  I don't agree with using information
>>>>> on users being stored in a spreadsheet.  It isn't what it was
>>>>> designed for.  It makes it to easy for a simple user error to make
>>>>> a mistake and corrupt the data.
>>>>>
>>>>

Note the question to which we responded:

>>>> I'm a bit confused by the statement about how information on users
>>>> shouldn't be stored in a spreadsheet, because it is so easy to
>>>> corrupt the data.
>>>>
>>>> Does this suggest that the only information that should be put in a
>>>> spreadsheet is data where it doesn't matter if it gets corrupted?
>>>>
>>>> If so, that would significantly reduce the usefulness of spreadsheets.
>>>>
>>>> I assume there is some key point that I'm missing, so please
>>>> enlighten .... thanks.

>>>>
>>>>
>>> Basically a database is for storing and retrieving information.  A
>>> spreadsheet is primarily for performing calculations on data.  In
>>> common usage, people have come to use spreadsheets to store
>>> information because the learning curve is much shallower than
>>> learning to work with a database.
>>
>> Also, a database can have fields, records and other areas locked to
>> protect data from user input or changes.  Spreadsheets can be sort of
>> locked but that isn't perfect either as I have seen so many times in
>> my work.
>>
>> A find and replace in a spreadsheet can be very dangerous if used
>> wrong.  A find and replace in a database is much harder to do outside
>> the current open record.
>>
>> Also, linking between data fields is much easier in a database.
>>
>> I agree that most users know how to use a spreadsheet and have to
>> learn a data base program.  It is well worth the time to learn how to
>> use a database program for storing records like employee information.
>>
>
>

--
Gene Y.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Mike Shearer]

I have abandoned using BASE and use CALC instead.  Very little of my
CALC data is numeric.  BASE was too hard to set up, the documentation
was more confusing than helpful.

But since the latest upgrade CALC has a serious bug.  Copying a cell
that is a formula into a set of other cells either crashes the job, or
the copying works but the calculated values are not displayed.
Something as simple as setting up a running total in a column (B2 =
B1+A2 etc), or setting a date column of every Monday in a year so that
the entries are automatically worked out (cell A1 = first date, then A2
=A1+7 and so on)

Mike Shearer
Townsville, Queensland, Australia

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Harold Fuchs-2]

On 07/07/09 00:10, Mike Shearer wrote:
> I have abandoned using BASE and use CALC instead.  Very little of my
> CALC data is numeric.  BASE was too hard to set up, the documentation
> was more confusing than helpful.
>
> But since the latest upgrade CALC has a serious bug.  Copying a cell
> that is a formula into a set of other cells either crashes the job, or
> the copying works but the calculated values are not displayed.

Errm. If you have a set of numbers in column A and then, starting in B3
you enter the formula "=A1+A2" then B3 will contain the sum of A1 and
A2. If you drag the formula down column B then
   B4 will contain the sum of B2 and B3
   B5                         B3     B4

etc.

If you now copy, say B5 into E5, E5 will contain **0**. Why? Because
Calc has automagically adjusted the formula to read "=D3+D4". This is
the way pretty much all spreadsheets work. When copying a *named* value
("A1" is a "name"), the name's two parts (row number and column letter)
are considered "relative" unless preceded by a "$" symbol.

Thus the value in cell A4 can be referred to in 4 different ways:
1. A4 meaning that both the A and the 4 are relative and thus subject to
automagic adjustment as above.
2. $A4 meaning the A is fixed (not subject to automagic adjustment) but
the 4 is relative. Copying such a value in the context above would
result in the column letter being copied as is but the row numbers being
adjusted as necessary.
3. A$4 meaning the A is relative but the 4 is fixed
4. $A$4 meaning both the A and the 4 are fixed.

It is worth playing with these combinations to see the differences. In
particular, try setting B3 in the above example to
1) =A$1+A$2 and then dragging B3 down column B
2) =$A$1+$A$2 and then, after dragging B3 down column B, copy/paste
column B into, say, column F.

Now, I'm not saying you haven't found a bug but your description of what
you see represents correct behaviour on Calc's part. Of course I don't
mean that "crashing the job" is correct behaviour. If you really get
that repeatedly please file a bug and let us know its number.

Please also tell us which version of OOo you are using and on which
version of which Operating System.


Something
> as simple as setting up a running total in a column (B2 = B1+A2 etc), or
> setting a date column of every Monday in a year so that the entries are
> automatically worked out (cell A1 = first date, then A2 =A1+7 and so on)
>
> Mike Shearer
> Townsville, Queensland, Australia


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[dotancohen]

> Also, a database can have fields, records and other areas locked to protect
> data from user input or changes.  Spreadsheets can be sort of locked but
> that isn't perfect either as I have seen so many times in my work.
>

Text files cannot be locked, should data not be stored in then? PIM
applications cannot be lock, should data not be stored in them?


> A find and replace in a spreadsheet can be very dangerous if used wrong.  A
> find and replace in a database is much harder to do outside the current open
> record.
>

have you never head of the "DROP * FROM table" without a WHERE clause
stories? That seems just a bit more dangerous to me. Furthermore, how
does an end user backup a database? Which files, exactly, does he
copy?


> Also, linking between data fields is much easier in a database.
>

Linking between data fields is not necessary for this application.


> I agree that most users know how to use a spreadsheet and have to learn a
> data base program.  It is well worth the time to learn how to use a database
> program for storing records like employee information.
>

It might be well worth the time for you. It might not be well worth
the time for any particular use case.


--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[dotancohen]

> /( sorry Dotan if I took the liberty to give this answer, but.... can they
> read the mail you wrote earlier ???)    ;-) /
>

No problem, Per.


--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[dotancohen]

> I have abandoned using BASE and use CALC instead.  Very little of my CALC
> data is numeric.  BASE was too hard to set up, the documentation was more
> confusing than helpful.
>

I should add that Base does not have a native enum command, yet Calc
does! This is a widely used feature in almost everything that I do.

--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[dotancohen]

>> But since the latest upgrade CALC has a serious bug.  Copying a cell that
>> is a formula into a set of other cells either crashes the job, or the
>> copying works but the calculated values are not displayed.
>
> Errm. If you have a set of numbers in column A and then, starting in B3 you
> enter the formula "=A1+A2" then B3 will contain the sum of A1 and A2. If you
> drag the formula down column B then
>  B4 will contain the sum of B2 and B3
>  B5                         B3     B4
>
> etc.
>
> If you now copy, say B5 into E5, E5 will contain **0**. Why? Because Calc
> has automagically adjusted the formula to read "=D3+D4". This is the way
> pretty much all spreadsheets work. When copying a *named* value ("A1" is a
> "name"), the name's two parts (row number and column letter) are considered
> "relative" unless preceded by a "$" symbol.
>
> Thus the value in cell A4 can be referred to in 4 different ways:
> 1. A4 meaning that both the A and the 4 are relative and thus subject to
> automagic adjustment as above.
> 2. $A4 meaning the A is fixed (not subject to automagic adjustment) but the
> 4 is relative. Copying such a value in the context above would result in the
> column letter being copied as is but the row numbers being adjusted as
> necessary.
> 3. A$4 meaning the A is relative but the 4 is fixed
> 4. $A$4 meaning both the A and the 4 are fixed.
>
> It is worth playing with these combinations to see the differences. In
> particular, try setting B3 in the above example to
> 1) =A$1+A$2 and then dragging B3 down column B
> 2) =$A$1+$A$2 and then, after dragging B3 down column B, copy/paste column B
> into, say, column F.
>
> Now, I'm not saying you haven't found a bug but your description of what you
> see represents correct behaviour on Calc's part. Of course I don't mean that
> "crashing the job" is correct behaviour. If you really get that repeatedly
> please file a bug and let us know its number.
>
> Please also tell us which version of OOo you are using and on which version
> of which Operating System.
>

Please start a new thread on that. If this thread was "almost
hijacked" earlier, it is certainly hijacked now.


--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Harold Fuchs-4]

"Harold Fuchs" <hwfa.openoffice@...> wrote in message
news:h2u3r4$6md$1@......

> On 07/07/09 00:10, Mike Shearer wrote:
>> I have abandoned using BASE and use CALC instead.  Very little of my CALC
>> data is numeric.  BASE was too hard to set up, the documentation was more
>> confusing than helpful.
>>
>> But since the latest upgrade CALC has a serious bug.  Copying a cell that
>> is a formula into a set of other cells either crashes the job, or the
>> copying works but the calculated values are not displayed.
>
> Errm. If you have a set of numbers in column A and then, starting in B3
> you enter the formula "=A1+A2" then B3 will contain the sum of A1 and A2.
> If you drag the formula down column B then
>   B4 will contain the sum of B2 and B3
>   B5                         B3     B4
>
> etc.
>
> If you now copy, say B5 into E5, E5 will contain **0**. Why? Because Calc
> has automagically adjusted the formula to read "=D3+D4". This is the way
> pretty much all spreadsheets work. When copying a *named* value ("A1" is a
> "name"), the name's two parts (row number and column letter) are
> considered "relative" unless preceded by a "$" symbol.
>
> Thus the value in cell A4 can be referred to in 4 different ways:
> 1. A4 meaning that both the A and the 4 are relative and thus subject to
> automagic adjustment as above.
> 2. $A4 meaning the A is fixed (not subject to automagic adjustment) but
> the 4 is relative. Copying such a value in the context above would result
> in the column letter being copied as is but the row numbers being adjusted
> as necessary.
> 3. A$4 meaning the A is relative but the 4 is fixed
> 4. $A$4 meaning both the A and the 4 are fixed.
>
> It is worth playing with these combinations to see the differences. In
> particular, try setting B3 in the above example to
> 1) =A$1+A$2 and then dragging B3 down column B
> 2) =$A$1+$A$2 and then, after dragging B3 down column B, copy/paste column
> B into, say, column F.
>
> Now, I'm not saying you haven't found a bug but your description of what
> you see represents correct behaviour on Calc's part. Of course I don't
> mean that "crashing the job" is correct behaviour. If you really get that
> repeatedly please file a bug and let us know its number.
>
> Please also tell us which version of OOo you are using and on which
> version of which Operating System.
>
>
> Something
>> as simple as setting up a running total in a column (B2 = B1+A2 etc), or
>> setting a date column of every Monday in a year so that the entries are
>> automatically worked out (cell A1 = first date, then A2 =A1+7 and so on)
>>
>> Mike Shearer
>> Townsville, Queensland, Australia

Apologies for aiding and abetting the crime of thread-hijacking. I never
noticed that I was replying to an off-thread question.

--
Harold Fuchs
London, England
Please do *not* reply to my personal e-mail address.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eike Rathke]

Hi Dotan,

On Friday, 2009-07-03 17:35:40 +0300, Dotan Cohen wrote:

> > But you are aware that the editing date format, as well as all default
> > display formats if nothing differently applied to a cell, depends on the
> > locale used on the system, and the locale can be overridden in
> > Tools->Options->LanguageSettings->Languages?
> >
>
> On my home machine, the system setting is to use the yyyy-mm-dd format
> and some applications, such as Thunderbird, respect that. Calc does
> not, I just tested. Kubuntu 9.04, OOo 3.1. Tell me where I err, not
> the LC_TIME is en_DK.utf8 which forces Thunderbird to give me
> yyy-mm-dd dates. Calc still does not.

OOo doesn't merge different LC_* settings into one locale, only one is
used, in precedence LC_ALL, LC_CTYPE, LANG. The RFE for that is
http://qa.openoffice.org/issues/show_bug.cgi?id=102517

  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the erl@... account, which I use for
 mailing lists only and don't read from outside Sun. Use erack@... Thanks.

[dotancohen]

> OOo doesn't merge different LC_* settings into one locale, only one is
> used, in precedence LC_ALL, LC_CTYPE, LANG. The RFE for that is
> http://qa.openoffice.org/issues/show_bug.cgi?id=102517
>

Thanks. These locale issues are terrible, they make OOo almost useless
for non-USians. Seriously, the more I get into it, the worst it gets.
Sadly, my OS has no alternative full-featured office suite.


--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[dotancohen]

>> Text files cannot be locked, should data not be stored in then? PIM
>> applications cannot be lock, should data not be stored in them?
>>
>>
> It would depend on the application and usage.  We store data in text files
> because they are thousands of lines long and we can insure they will be
> accessible 5 years down the road where we cannot in a binary file format.
>

Which is not different from what Latet is doing with their Calc spreadsheets.


>> have you never head of the "DROP * FROM table" without a WHERE clause
>> stories? That seems just a bit more dangerous to me. Furthermore, how
>> does an end user backup a database? Which files, exactly, does he
>> copy?
>
> No I have not.  But I have seen someone wipe out a spreadsheet with a simple
> keystroke.  Any tool has ways of destroying the data but if it is setup
> properly the ability to corrupt data is much harder.
>

There are enough horror stories about the no-WHERE-clause DELETE
statements. What single keystroke could wipe out a spreadsheet?

>>> Also, linking between data fields is much easier in a database.
>>>
>>
>> Linking between data fields is not necessary for this application.
>
> I don't know.  I have not seen the spreadsheet.  If it is just records to be
> calculated then no problem.  I read that there were employee numbers being
> used and to me, this points to linking data between data identifying an
> employee with extra data.  I am thinking in terms of how I would do it.
>

Actually, they are volunteers not employees, but the idea is the same.
There is no link to other data, though, just one row per volunteer
with some information. One of the columns is an enum, something that
is not native in Base.


> Again if you feel that spreadsheets are a good place for database data, then
> this is a valid comment.  If the data is simple like an address book, then a
> spreadsheet meets the requirements.
>

Yes, this is like an addressbook.


> Here is a simple document that I feel covers this quite well.
>
> Using a spreadsheet as a database - what works, what doesn't' work.
> http://www.plumsuite.com/Articles/Using%20a%20spreadsheet%20as%20a%20database.pdf
>

Nice, but nothing new there for me. If it were in Hebrew I would pass
it on, but really it says nothing (other than the story) that I have
not already told them. Yes, a database would be _better_, but a
spreadsheet is _easier_ for them.


> Consider moving your database into Access or creating it there if your needs
> include:
> • Screen forms arranged in a particular way, or that do not show all fields

Negative

> • Keeping your data consistent in particular fields

Positive

> • A “bulletproof’ application for routine entry by unskilled workers

Positive. however, which unskilled worker is going to make the tables,
forms, and reports?

> • Linked tables to avoid data redundancy

Negative

> • More than one person using the data at the same time

Positive, but they will be on the same terminal so it doesn't matter.

> • Keeping old data for future reference

Positive


> But this debate doesn't solve the issue of what went wrong with the data in
> the first place by the OP but is useful to those that want to know why and
> when to use a database over a spreadsheet should be considered.
>

I do, however, feel that the rounding issue would not have occured in
Base. That I will contend.


> If the spreadsheet is written properly, it shouldn't be that hard to export
> it to Base from Calc.  I have not tried it yet.
>

It was written properly, that much I can say.


--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Phil Hibbs]

Firstly: the correct way to store this information in a spreadsheet
would be to format the column as Text. That would prevent anything
like "Precision as shown" from affecting the data. ID numbers aren't
really numbers, since it is meaningless to do mathematical operations
on them.

Secondly: I had a similar problem recently in Excel, where we have a
sheet with VBA code that opens a list of other spreadsheets and writes
out the data in the other sheets as a CSV file. It was writing the
data as displayed, so 123456789 came out as "1E+09". Fixed it by
adding a "Columns.AutoFit" method call on the sheet object.

Phil Hibbs.
--
Don't you just hate self-referential sigs?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[dotancohen]

>> have you never head of the "DROP * FROM table" without a WHERE clause
>> stories? That seems just a bit more dangerous to me. Furthermore, how
>> does an end user backup a database? Which files, exactly, does he
>> copy?
>
> No I have not.  But I have seen someone wipe out a spreadsheet with a simple
> keystroke.  Any tool has ways of destroying the data but if it is setup
> properly the ability to corrupt data is much harder.
>

http://thedailywtf.com/Articles/Death-by-Delete.aspx


--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[NoOp-4]

On 07/05/2009 11:53 PM, Dotan Cohen wrote:

>> OK - done. I suspect operator error and/or some other problem with your
>> rounding issue. I have tested (as you suggested:
>>
>> <quote>
>> in 2.x try entering this into a cell:
>> 317907977. Open it and modify in a later version of 2.x then in 3.0
>> then 3.1. See if it rounds up.
>> </quote>
>>
>> with WinXPPro:
>>
>> 2.4.1 ==> 2.4.2 ==> 3.0.0 ==> 3.1.0
>>
>> No rounding errors, no issues.
>>
>> I created a file for each version & can send to you directly if you wish.
>>
>
> Thanks. Send to me the latest, I will see if it rounds here and at the
> Latet office.
>

I sent you all 3, did you get them?



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[dotancohen]

> I sent you all 3, did you get them?
>

Yes, thanks. I have not been to the Latet office lately due to exams.
I will report back when I get the chance, sorry for the delay. Thank
you!

--
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[drewjensen]

Dotan Cohen wrote:
> There are enough horror stories about the no-WHERE-clause DELETE
> statements. What single keystroke could wipe out a spreadsheet?
>
>  
hmm - highlight all the rows/columns (kind of like writing that delete
statement)
then.....
hit <del>
(granted that is only a sheet)

or

close your spredsheet - go to your file browser - highlight the file
then....
hit <del>

Does that count?

OK so in the first instance you could use UNDUE to get the data back.

In a relational database there is a concept of a transaction.
Any DBA (worth their salt) would know that when doing mass deletes (or
updates)
the process is:
Start Transaction
Perform your mass change
CHECK YOUR WORK
If it is correct
   COMMIT (this makes it permanent)
if not
   ROLLBACK (this will UNDUE the chagnes )

For the second example one needs to go to the Backups.
Yes you can backup a database also.

Drew

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[drewjensen]

> Positive. however, which unskilled worker is going to make the tables,
> forms, and reports?
>
>  

AHHH - none - that is why they hire a contractor - or take a class - or
read a manual - or come to a mailing lists.

Unless you are contending that an unskilled worker can create a proper /
validated spreadsheet application without doing any of the above.

Drew

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...