Maybe you have indeed too many options in your configuration file. Can you please post it here or send it to my privately so that I can have a look?

- Stefan 

Hallo and thanks for a great program.

At my work we have previously been using another program (Rednotebook) for our lab journals, but now we wish to migrate to elog because it is more configurable and because it runs in a browser.

We would off course like to move all of our old log entries with us. Luckily Rednotebook uses a standard module (YAML) for data storage, so I can easily access the data (e.g. with python) and I have already done do, and I have exchanged the native markup with html.

Now I would prefer it if I can make the elog data files directly, in stead of using the elog command, because that makes it possible and easy to revert the change, and also to not have to handle escaping html string before feeding them to elog on the commandline. I have actually already written the program that produces the elog data files, but now I have a few questions:

1) Is there an overall way of validating the datafiles, to make sure elog doesn't choke on them at some point in the future when I try to open one of the old entries. Along the same lines, does elog parse all the files when the demon is started, so if it starts then I'm ok?

2) What exactly are the requirements for the HTML content

2a) Will any valid html do, or are there some speciel requirements (e.g. like   at blank lines)

2b) Does it require a particular version of html, because then I could at least validate it against that doctype beforehand

3) Is there a log from elog where I can see if it encounters something it doesn't like?

I hope the you can answer some of my questions.

Regards Kenneth

 I haven't found anything in the forums about this. Apologies if its a duplicate.

I am fairly familiar with ELog, use it for multiple purposes on 5 different Virtual Servers at work. 

Currently looking to do some updates to one of the instances with the Date Type setting.

We have 17,000 entries all which have had manual entries for a Date Attribute for the last year and 8 months.

Due to regular entry errors on part of our contractors using it, (Eg: using "Aug" instead of "08", or using "-" instead of "/"), I want to change over to using the date type attribute (Type <attribute> = Date).

However the problem i found, the moment i save this in the config, and go to the list of entries, the date has changed on all of the entries to 12/31/1969. Which is BAD for our operation. So after removing the Type Date Setting the dates go back to normal.

Is there anyway to retain those dates so they display as they are and then only new entries would fall under the new date type setting?

Syntax manual didn't help much for this issue.

 Hi Garret,

Why cannot you just use $entry time ?  It uses the date that the entry was made which appears as the first line of every elog entry -

[Sorry for mis-post, just discovered cannot put the 'dollar at' control set in an entry]

MID: 12458
Date: Fri, 07 Sep 2012 17:22:06 +0100
In reply to: 12453
 

You can use 'Time format = ' to get the date to display in the format you like.  You will see I have posted an issue about 'Date format = '.  I mention this because in trying to understand what was happening, I too had a case where all the dates were showing as the same in a thread.  I suspect your 12/31/1969 was due to the entries as being read were non-existant or blank.

Of course I may have mis-understood your requirements.

 Tried using the Time format setting, however I only want the time to be selected, so when i enter the datetime type it shows the date and time.

If there was a way to just have the time to be drop down menus vs the date and time all together, I would find that helpful.

As for the "$entry time" suggestion, it only serves to log the exact time the entry was made into elog. Where as I want it to be manually set.

In this example we've created an sql script to pull information from an oracle database, which then creates an elog entry.

We have multiple fields which are populated and locked so only admin can edit them.

Our contractor then edits the entry with a date / time / location, and a few other things.

the Date and Time are separate attributes. We'd prefer to keep it like that just because of the other scripts that run on the elog entries, (pulls day by day reports and formats and calculates summaries in excel automatically).

Any other suggestions would be helpful.

Thanks for your reply.

Hi Stefan,

I have observed following behavior when I move entries from one logbook to another:

1. The first entry in "Open" get ID "1"
2. When I move this Item to "Closed", it will keep ID "1" as I have used "Preserve IDs = 1"
3. A new entry in "Open" gets ID "1" again
4. When I move this item to "Closed" it will overwrite the previous ID "1" in "Closed"
5. A new entry in "open" gets ID "1" again....

Every new entry in "Open" will get the next higher ID Number related to the highest available ID number/entry in "Open".

Upon "move to Closed", the previous entries in "Closed"will be overwritten.

Is there a way to prevent the usage of a previously used ID Number when entering a new ID?
I.e. If an entry with ID "1" has been used in "Open" and moved to "Closed", have the next entry in "Open" use ID "2"?

Kind regards,

Barend

 Hi Barend,

The counting of entries, or even "tickets", only works within a particular logbook.  If you archive a set of entries to another [archive] logbook, the archived set disappears from view of the original logbook.  Should that entry, from logbook to archive, be the *latest* thread, then there is the danger of over-writing message ID, Ticket No and the like.

My policy to prevent the problem is to archive only threads that are say (depending upon use) a month after last entry..