Am 13.09.2012 00:49, JAMES MAJESKI wrote:
Name one feature that makes a database better than a spreadsheet when
flexibility of input is required.
--
View this message in context:
Am 13.09.2012 05:18, JAMES MAJESKI wrote:
So far nobody has come up with a reason for me to switch to a database where
I risk loosing data if I attempt to make a change to the layout.
--
View this message in context:
Am 13.09.2012 05:03, JAMES MAJESKI wrote:
My only queries of the data are handled adequately by the calculations done
in adjacent columns. Nothing special, complex, or complicated will easily
replace it nor be more useful.
Calc can do all this without very easily with the help of the Base
Am 13.09.2012 11:54, Andreas Säger wrote:
Am 13.09.2012 05:03, JAMES MAJESKI wrote:
My only queries of the data are handled adequately by the calculations
done
in adjacent columns. Nothing special, complex, or complicated will easily
replace it nor be more useful.
Calc can do all this
Am 10.09.2012 22:30, Andreas Säger wrote:
Am 10.09.2012 19:40, Andreas Säger wrote:
Base is our database component. It is very, very underdeveloped,
nevertheless underestimated. Even the worst database tool does a better
database job than the best spreadsheet can do.
Since nobody ever
Hi :)
Ahhh, we shorten MS Office to MSO. It might be only LibreOffice lists and a
few other such places that use it that way.
Regards from
Tom :)
From: JAMES MAJESKI jamesmaje...@gmail.com
To: users@global.libreoffice.org
Sent: Thursday, 13 September
Andreas Säger wrote:
*Because* spreadsheets are so flexible you can not edit databases with them.
Simply because all you have is a database excerpt in plain text. You never
asked for flexibility. You asked for data integrity (keep the exact same
date encoding when saving back to a database
My research has convinced me that I do not have neither the time nor the
resources to set up and maintain a database. I might consider it if all of
the data were received in the same layout, but the layout is as varied as
are the sources. Since I am the only one that is using the data, a
Am 12.09.2012 07:23, JAMES MAJESKI wrote:
Two digit years have always been a problem. I always presume that the use two
digit years was obsolete after the Y2K publicity, but bad habits continue.
We are no longer in the era of eighty column punch cards, so there is no
excuse for two digit years.
Am 12.09.2012 08:00, JAMES MAJESKI wrote:
My research has convinced me that I do not have neither the time nor the
resources to set up and maintain a database. I might consider it if all of
the data were received in the same layout, but the layout is as varied as
are the sources. Since I am the
On 09/12/2012 01:23 AM, JAMES MAJESKI wrote:
Two digit years have always been a problem. I always presume that the use two
digit years was obsolete after the Y2K publicity, but bad habits continue.
We are no longer in the era of eighty column punch cards, so there is no
excuse for two digit
Hi :)
I think all these tools require skill and experience. It's easiest to keep
using the tool you have most skills and experience in but at the same time it
is a good idea to try to build-up experience with other tools.
If Andreas was working with your data then a database-program would be
On 09/12/2012 02:00 AM, JAMES MAJESKI wrote:
My research has convinced me that I do not have neither the time nor the
resources to set up and maintain a database. I might consider it if all of
the data were received in the same layout, but the layout is as varied as
are the sources. Since I am
I looked into it and decided against it because what I am doing requires an
intermediate spreadsheet in most cases. Since I now have many different ways
to import the data so that it is correctly formatted, the extension would
probably never be used. Detect special numbers and paste special
As I said before, getting the date into a spreadsheet as a date was the
problem. Once there, I am able to format the data as required.
CSV was just an example. I get the data in just about any format (raw
(unformatted), comma delimited, tab delimited, xls, xlsx, doc, docx, txt,
pdf, etc. Even
Name one feature that makes a database better than a spreadsheet when
flexibility of input is required.
--
View this message in context:
http://nabble.documentfoundation.org/Date-will-not-format-or-sort-when-imported-into-calc-ods-tp4004907p4007128.html
Sent from the Users mailing list archive
The problem is that I see no advantage in a database. I do see many
disadvantages. For what I am doing, a database is not an option.
--
View this message in context:
http://nabble.documentfoundation.org/Date-will-not-format-or-sort-when-imported-into-calc-ods-tp4004907p4007129.html
Sent from
Once I have the data imported into the spreadsheet, there are no problems
with dates. It was the importation of the dates that caused the problem. As
for date formats, I prefer ISO8601 as I was using that format in the sixties
and I never stopped. I can accommodate any *unambiguous* date and time
Hi :)
Sometimes on this list we bully, cajole or otherwise try to push people into
using tools they are not familiar with. Even if it's a better tool for the
task, that doesn't always make it better for the person's work-flow.
There is only one right way of doing things and that's your
My only queries of the data are handled adequately by the calculations done
in adjacent columns. Nothing special, complex, or complicated will easily
replace it nor be more useful.
I can see how a database between libraries would benefit all the libraries
that subscribe to the common database,
So far nobody has come up with a reason for me to switch to a database where
I risk loosing data if I attempt to make a change to the layout.
--
View this message in context:
http://nabble.documentfoundation.org/Date-will-not-format-or-sort-when-imported-into-calc-ods-tp4004907p4007154.html
Two digit years have always been a problem. I always presume that the use two
digit years was obsolete after the Y2K publicity, but bad habits continue.
We are no longer in the era of eighty column punch cards, so there is no
excuse for two digit years.
ISO8601 is the international standard, so
The following is a reply to my query from a private source:
Data bases are for fixed data columns and standardized input methods and
require manipulation by sql type query tools. Unless you are getting
automatic feeds of significant amounts of data from your world wide
operations I don't see what
Am 10.09.2012 01:49, JAMES MAJESKI wrote:
You are correct in that 12/31/12 is not ambiguous, but that is a special
case. When each element is unique and without knowing the source preference,
there are six different dates that may be generated from 10/11/12:
2010-11-12
2010-12-11
2011-10-12
Am 10.09.2012 18:56, JAMES MAJESKI wrote:
The following is a reply to my query from a private source:
Data bases are for fixed data columns and standardized input methods and
require manipulation by sql type query tools. Unless you are getting
automatic feeds of significant amounts of data from
James
CT2N is a Libre extension, not a file extension
http://extensions.libreoffice.org/extension-center?getCategories=getCompatibility=anysort_on=positive_ratingspath=%2FLibreOffice-Extensions-and-Templates%2Fextension-centerportal_type=PSCProjectSearchableText=CT2N
Load this into the Libre
Use the extension CT2N.
It Converts Text to Numbers.
Simples.
Tink.
--
View this message in context:
http://nabble.documentfoundation.org/Date-will-not-format-or-sort-when-imported-into-calc-ods-tp4004907p4006356.html
Sent from the Users mailing list archive at Nabble.com.
--
For
Am 09.09.2012 11:54, Tinkerer wrote:
Use the extension CT2N.
It Converts Text to Numbers.
Simples.
Tink.
Nobody needs to install any extension to convert between numbers and
text. CT2N may fail in this situation (dmy vs. mdy).
If all the dates have been imported as text, a simple regex
In a spreadsheet I get all the information I require and it is easy to get
additional information if needed. I can add, modify, and delete headers both
horizontally and vertically. I can add, modify, or delete cells, rows, or
columns at will. As long as I leave the original data alone, I can add
When I change the file extension (file_name.ct2n), I find no difference in
how the file is imported into a spreadsheet.
--
View this message in context:
http://nabble.documentfoundation.org/Date-will-not-format-or-sort-when-imported-into-calc-ods-tp4004907p4006429.html
Sent from the Users
With the advice given earlier, I have found several methods that do what I
need to get done with no problems. My previous lack of knowledge was easily
corrected and I am confident in my ability to adapt the input to conform to
the requirements of its intended function.
Quote: [With US loale
On 09/09/2012 06:51 PM, JAMES MAJESKI wrote:
In a spreadsheet I get all the information I require and it is easy to get
additional information if needed. I can add, modify, and delete headers both
horizontally and vertically. I can add, modify, or delete cells, rows, or
columns at will. As long
32 matches
Mail list logo
