Hello all,

i have a question to mysql inexecute:

This works:

Execute new = mysql -h localhost -u root -D test1 -e "insert into `test1` (author, type) values ('$Author', '$Type')"

This doesn't work:

Execute new = mysql -h localhost -u root -D test1 -e "insert into `test2` (Autor, Adressat, Teil1, Teil2, Teil3,
Teil4, Teil5, Teil6, Teil7, Teil8 )  values ('$Autor', '$Adressat' ,  '$Teil1', '$Teil2', '$Teil3', '$Teil4', '$Teil5',
'$Teil6', '$Teil7', '$Teil8' )"

db is okay, i have all checked this. My question is: can the execute-command take a multiline argument? Or perhaps does somebody see a mistake i have made in the execute-line?

Thanks!

Steve

In the elogd.cfg file, you cannot have multi-line options. Either you put everything on a single line (I guess there is also some limit at a few hundred characters) or you call a batch file which then calls the mysql command. 

 Thanks!

Here is an excerpt from my config file:

Type Last Edit = datetime
Preset Last Edit =$entry time
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Preset on Duplicate Last Edit = $date

I have another attribute called Part that I've made extendable.

When I duplicate an entry, Last Edit is updated with the current date correctly. However, as soon as I click the Add Part button next to my extendable Part attribute, and the page reloads to show the entry box for the Part field, the Last Entry field is replaced with a "-".

I have to submit and then re-edit the entry to get Last Edit to have a valid value again.

 *EDIT*:

I noticed that any time the page reloads while in the entry screen this happens, e.g. by selecting plain instead of html format.

 Thanks for reporting that problem. It has been fixed in SVN revision 2156.

 Excellent! Thank you.

When doing a Select->Edit operation, if an attribute has a type of "numeric" and the records selected already have (some) values for that attribute, then the "- keep original values -" message that is inserted to indicate that the values should be preserved causes the type check to fail.

Would it be possible to modify the Javascript that carries out the type check to treat the "- keep original values -" message as an exception?

 Thanks for reporting this. It has been fixed in SVN revision 2155. The fix will be contained in the next release.

 I would like to be able to substitute some attribute values when an entry is duplicated. I don't see Subst on Duplicate available in the cfg file syntax. Can you add that?

Thanks

Subst on Duplicate does not make sense. Subst always works after you submit an entry, while Preset works before you enter the entry. When you Duplicate an entry, it looks like a new one, just with attributes and text from another entry. So when you submit that one, the system cannot distinguish if you entered a new one by yourself or if this is based on a copy of another entry. So what you probably need is Preset on duplicate.

Thanks for explaining.

I thought Preset would work with Duplicate since Duplicate creates a new entry, but it didn't. Then I tried Subst because Duplicating an entry opens it in Edit mode, so you are in effect Duplicating, and then Editing the entry. It just didn't occur to me to look for Preset on Duplicate.

Attributes = Author, Type, Last Edit
Type Last Edit = datetime
Preset Last Edit =$date
Locked Attributes = Last Edit
Start page = ?rsort=Last Edit

We have an auto-incrementing reference attribute defined as:

# RFC

Format RFC = 0,narrowattribname,narrowattribvalue,60,60
Preset RFC = RFC-######
Preset On Duplicate RFC = RFC-######
Tooltip RFC = A unique reference will be generated for this Request For Change

We also have a "Created by/when" attribute.  Looking at the values this seems to be set when the user clicks "New" whereas the time stamp that appears on the line after the  $@MID@$ seems to be set when the user clicks "Submit".

# Created

Format Created = 0,attribname,attribvalue,70,100
Preset Created = $long_name ($short_name) on $date
Preset On Duplicate Created = $long_name ($short_name) on $date

Every once in a while the incrementing stops working and the number 'sticks' or misses some out.  It looks as if it might be because multiple people are adding entries concurrently.  Could the occasion where there is a gap in the sequence (171-174) be where people abandoned changes (clicked on "Back") after having numbers allocated?  Here is a list showing the discrepancies.

Date        Item     Time Stamp (from the line after $@MID@$)  "Created" attribute time stamp

22/09/08    124      16:15:10                                   11:58

22/09/08    125      16:33:54                                   16:24

22/09/08    125      16:35:37                                   16:33              Should be 126

...

10/10/08    146      10:39:09                                   10:30                    Correct

10/10/08    146      10:46:57                                   10:35              Should be 147

10/10/08    147      13:04:03                                   13:02              Should be 148

10/10/08    148      15:11:38                                   15:00              Should be 149

...

17/11/08    171      10:21                                      10:17              Correct

17/11/08    174      14:30                                      13:47              Should be 172

17/11/08    175      16:14                                      16:04              Should be 173

17/11/08    176      16:49                                      16:38              Should be 174

...

25/11/08    187      15:49:58                                   15:47              Correct

25/11/08    187      15:52:39                                   15:48              Should be 188

25/11/08    188      16:49:56                                   16:44              Should be 189

25/11/08    188      16:52:40                                   16:40              Should be 190

25/11/08    188      16:55:17                                   16:43              Should be 191

Let me know if you need any more information.

regards

Steve

 Hi

This is to let you know that the increment problem has just happened again.

Item 206 has timestamp (from the line after $@MID@$) of 11:59:45 and "created" attribute timestamp of 11:29

overlapping with this, a second item 206 has timestamp of 12:04:02 and "created" attribute of 11:53

So, both users were entering information between 11:53 and 11:59:45 and both picked up the same increment number.

There's no easy solution tho, is there? If you pick up the increment number at the start so it can be displayed on screen and ensure uniqueness then, if a user cancels a new entry you end up with "holes" in the sequence.  If you pick it up at the end then you can't display it until the user presses submit.

regards

Steve

I finally found some time to address this problem. It is indeed related to the fact that the new number gets assigned when you click on 'New'. So if two people edit the new entries at the same time, they get assigned the same number. To fix this problem, I made the tag generation work with the 'Subst' command, which is evaluated at the entry submission, and not when you click on 'New'. So to make this work, you need to upgrade to SVN revision 2152 and then put into your configuration file: 

Attributes = Author, RFC, Subject
Preset RFC = <will be assigned when you submit>
Preset on duplicate RFC = <will be assigned when you submit>
Locked attributes = RFC  Subst RFC = RFC-######

I also changed the documentation accordingly.

Attributes = Author, RFC, Subject
Preset RFC = <will be assigned when you submit>
Preset on duplicate RFC = <will be assigned when you submit>
Locked attributes = RFC  Subst RFC = RFC-######

 Stefan

Thanks for fix - I've just tested it and it works beautifully.

regards

Steve

I copied the following line from the ELOG documentation file to my config file (with the appropriate changes to the attribute and value fields) and nothing happens. Am I missing something?

Style importance severe = background-color:red

Thanks for all your help.

Style importance severe = background-color:red

Thanks for all your help.

 Just the "usual candidates":

• Any typo?
• Edited the wrong file?
• Must send a HUP signal to elogd if running under linux
• Note that the style changes only in the list display

I just tried with a minimal configuration file:

[demo]
Attributes = Author, Importance, Subject
Options Importance = normal, severe
Style Importance severe = background-color:red

and it just worked fine:

I want to know if there were some way to insert a screen shot directly into the log book instead of going through the "save-attach" procedure. i.e. add some plug in button to do this under Linux?

Or, can I just make a plain log file "xxxx.log" and put it into the directory? Will that work?

Thanks

You cannot directly paste a screen shot into an elog entry. Use HoverSnap (Windows) or ksnapshot (linux) to produce directly an image file, then you need only two mouse clicks (browse and select file). There is also an Add-On for FireFox called "dragdropupload" which can be used for drag-and-drop a file into the attachment file selector. 

 I see. But what I want to do now is writing a script to make a elog entry, is that possible? I mean, I don't know if the log entry I generated could be recognized by elog.  e.g. the following text is generated by me, no through elog, is there a way to let them shown on elog?

Date: Mon, 01 Dec 2008 18:45:21 -0500
Author: Anonymous
Author Email: $user_email
Category: Shift summary
Subject: test
Attachment: 081201_184113_bigcal_014.jpg
Encoding: HTML
========================================
test
 

 For what you need you can use the "elog" utility, as described in https://midas.psi.ch/elog/userguide.html at the bottom. Using the "-f" option you can add attachments there.

 Got it! This is exactly what I need, thanks a lot!