Re: Data Export:: Date Problem, posted by Stefan Ritt on Mon Feb 11 22:24:37 2008
|
| Richard Ecclestone wrote: |
|
Hi
Im currently experimenting with Elog to see if we can use it to track maintenance work. But Ive come up against a problem, When I export the data to a csv file,
the date has a comma inserted between the day of the week and the rest of the date. This means that all the fields are then shifted to the right after the date.
This looks like a bug to me, the test records included in the demo does not exhibit this problem, until a new record is added.
|
What about exporting record separated by a semicolong ";" ? |
|
Re: Data Export:: Date Problem, posted by Stefan Ritt on Mon Feb 11 22:33:37 2008
|
| Stefan Ritt wrote: |
|
| Richard Ecclestone wrote: |
|
Hi
Im currently experimenting with Elog to see if we can use it to track maintenance work. But Ive come up against a problem, When I export the data to a csv file,
the date has a comma inserted between the day of the week and the rest of the date. This means that all the fields are then shifted to the right after the date.
This looks like a bug to me, the test records included in the demo does not exhibit this problem, until a new record is added.
|
What about exporting record separated by a semicolong ";" ?
|
I fixed that in SVN revision #2040, the comma is simply replaced by a space in the date string. |
|
Re: Data Export:: Date Problem, posted by Richard Ecclestone on Tue Feb 12 08:54:48 2008
|
| Stefan Ritt wrote: |
|
| Stefan Ritt wrote: |
|
| Richard Ecclestone wrote: |
|
Hi
Im currently experimenting with Elog to see if we can use it to track maintenance work. But Ive come up against a problem, When I export the data to a csv file,
the date has a comma inserted between the day of the week and the rest of the date. This means that all the fields are then shifted to the right after the date.
This looks like a bug to me, the test records included in the demo does not exhibit this problem, until a new record is added.
|
What about exporting record separated by a semicolong ";" ?
|
I fixed that in SVN revision #2040, the comma is simply replaced by a space in the date string.
|
Hi Stefan
Thanks for the quick reply.
We seem to be running 2012 - Which may explain the problem - I will see with our system administrator why we are not running 2040. By the way I also had this problem when running the windows version.
Cheers.. Richard |
|
Re: Data Export:: Date Problem, posted by Richard Ecclestone on Tue Feb 12 10:52:17 2008
|
| Richard Ecclestone wrote: |
|
| Stefan Ritt wrote: |
|
| Stefan Ritt wrote: |
|
| Richard Ecclestone wrote: |
|
Hi
Im currently experimenting with Elog to see if we can use it to track maintenance work. But Ive come up against a problem, When I export the data to a csv file,
the date has a comma inserted between the day of the week and the rest of the date. This means that all the fields are then shifted to the right after the date.
This looks like a bug to me, the test records included in the demo does not exhibit this problem, until a new record is added.
|
What about exporting record separated by a semicolong ";" ?
|
I fixed that in SVN revision #2040, the comma is simply replaced by a space in the date string.
|
Hi Stefan
Thanks for the quick reply.
We seem to be running 2012 - Which may explain the problem - I will see with our system administrator why we are not running 2040. By the way I also had this problem when running the windows version.
Cheers.. Richard
|
Hi Stefan
Our IT administrator has just downloaded and installed the latest source code from the site and installed it. We still now have version 2012?
Where do we get version 2041 ?
Cheers, Richard
|
|
Re: Data Export:: Date Problem, posted by Stefan Ritt on Tue Feb 12 11:42:01 2008
|
| Richard Ecclestone wrote: |
|
Our IT administrator has just downloaded and installed the latest source code from the site and installed it. We still now have version 2012?
Where do we get version 2041 ?
|
The bleeding edge version you get always from our SVN server, but you have to recompile it yourself. For your convenience, I just made you a version 2.7.2-3 containing the latest source code. |
|
Re: Data Export:: Date Problem, posted by Richard Ecclestone on Tue Feb 12 20:40:53 2008
|
| Stefan Ritt wrote: |
|
| Richard Ecclestone wrote: |
|
Our IT administrator has just downloaded and installed the latest source code from the site and installed it. We still now have version 2012?
Where do we get version 2041 ?
|
The bleeding edge version you get always from our SVN server, but you have to recompile it yourself. For your convenience, I just made you a version 2.7.2-3 containing the latest source code.
|
Thanks Stefan
Everything works now. |
|
Re: Absolut links for images in FCK Editor, posted by Jochen Krempel on Tue Feb 12 23:57:52 2008
|
| Stefan Ritt wrote: |
|
| Jochen Krempel wrote: |
|
We use ELOG inside a local network, but we want to allow access also from outside the firewall.
The suggested solution from Elog Admin Guide worked fine until version ELOG V2.6.5-1844 (essentially without FCK Editor):
ssh -L 1234:your.server.name:8080 your.firewall.name
firefox http://localhost:1234/
Howerver, since the update to ELOG V2.7.1-2002 the FCK Editor uses absolute links to insert images.
An image uploaded from the local network will have an address like:
http://your.server.name:8080/logbookname/080207_101110/Picture.jpg
while the same image uploaded through the firewall tunnel will have a link like:
http://localhost:1234/logbookname/080207_101110/Picture.jpg
Obviously images uploaded from outside are not visible from inside and vice versa.
Is it possible to convince FCK Editor to use relative links?
PS
ELOG is great!!
|
I fixed this in SVN revision #2038.
|
Thank you for the quick support! |
|
Re: move mxml code into elog's src directory, posted by Stefan Ritt on Fri Feb 15 06:59:52 2008
|
| Jeff Stoner wrote: |
|
The mxml source code should be moved into the elog-*/src directory. This requires changing the Makefile to:
MXMLDIR = src/mxml
Reason for change: if you want to build several versions of elog and you unpack the distributions in the same top-level directory, the most recently unpackaged version will overwrite the mxml directory contents, possibly introducing bugs.
|
From your point of view that request is reasonable, but the reason of having mxml in a separate top level directory is that I use it in many different projects. If I would keep a copy of mxml in each project, I would have to update all of them manually if there is a bug. On the other hand the code of mxml changes very seldom. If you look at the history, it got ~5 changes last year, while elog itself had hundreds. And since I do not change the API, a bugfix in mxml should be to the benefit of all elog versions. It is like with other projects which depend on a number of packages. Like if you install Apache for example, you need a certain version of OpenSLL, a certain version of libcrypt, and so on. So think of mxml like another package you have to combine with elog. |