Re: Install on Server 2003: , posted by Stefan Ritt on Mon Sep 15 16:34:18 2008
|
| Wythe IT wrote: |
|
I am using Windows Server 2003 R2 Standard Edition. It is up-to-date and a full legal version installed from a geniune MS disk (to put that notion out the way). I host a variety of webpages from this server through IIS6.0.
I am having an issue after installation of the ELOG software. I grabbed the newest version from this website and ran the executable. It installed fine (or appeared to do so).
Upon starting the ELOG server I receive the following error:
elogd.exe - Unable to Locate Component
This application has failed to start because MSVCR71.dll was not found. Re-installing the application may fix this problem.
The file in question is part of an ancient Visual C distributeable. This distributeable for my purposes no longer appears to be available (as I am on .net 3.5). I am unsure of downloading the older runtime libraries from sites that are not microsoft's. I am curious as to how I could go about making elog execute. Any help would be appreciated. Thank you!
|
I didn't realize that MSCVR71.dll is kind of outphased. I will add it to future distributions. For the moment, you can download it from the elog server directly. |
|
Re: Install on Server 2003: , posted by Wythe IT on Mon Sep 15 18:49:33 2008
|
| Stefan Ritt wrote: |
|
| Wythe IT wrote: |
|
I am using Windows Server 2003 R2 Standard Edition. It is up-to-date and a full legal version installed from a geniune MS disk (to put that notion out the way). I host a variety of webpages from this server through IIS6.0.
I am having an issue after installation of the ELOG software. I grabbed the newest version from this website and ran the executable. It installed fine (or appeared to do so).
Upon starting the ELOG server I receive the following error:
elogd.exe - Unable to Locate Component
This application has failed to start because MSVCR71.dll was not found. Re-installing the application may fix this problem.
The file in question is part of an ancient Visual C distributeable. This distributeable for my purposes no longer appears to be available (as I am on .net 3.5). I am unsure of downloading the older runtime libraries from sites that are not microsoft's. I am curious as to how I could go about making elog execute. Any help would be appreciated. Thank you!
|
I didn't realize that MSCVR71.dll is kind of outphased. I will add it to future distributions. For the moment, you can download it from the elog server directly.
|
Thank ya much. Worked perfectly. For others with this issue, download that linked file to your c:\windows\system32\ folder. |
|
Re: Inserting images via Internet Explorer, posted by Stefan Ritt on Thu Jul 13 15:16:53 2006
|
| Elaine Cristina Franchini dos Anjos wrote: | I observed that there is a difference between IE and others browsers.
When I use "insert image" button in Netscape, for instance,
it creates automatically a tag like [IMG]elog:1/1[/IMG] and
includes an attachment in the ELOG entry.
When a try to do the same action in Internet Explorer, only
the attachment is created without the tag [IMG]elog:1/1[/IMG] . |
This is a problem of the JavaScript implementation of Internet Explorer. After some externsive research I found now a way to convince IE to do the right thing. The fix is contains in SVN revision 1701 and will be released with 2.6.2-2 soon. |
Re: Inserting images via Internet Explorer, posted by Elaine Cristina Franchini dos Anjos on Fri Jul 14 20:29:21 2006
|
| Stefan Ritt wrote: |
| Elaine Cristina Franchini dos Anjos wrote: | I observed that there is a difference between IE and others browsers.
When I use "insert image" button in Netscape, for instance,
it creates automatically a tag like [IMG]elog:1/1[/IMG] and
includes an attachment in the ELOG entry.
When a try to do the same action in Internet Explorer, only
the attachment is created without the tag [IMG]elog:1/1[/IMG] . |
This is a problem of the JavaScript implementation of Internet Explorer. After some externsive research I found now a way to convince IE to do the right thing. The fix is contains in SVN revision 1701 and will be released with 2.6.2-2 soon. |
Great job !
I tried the SVN revision 1701, and it works perfectly.
Thank you for all your effort.
Regards,
Elaine |
|
Re: Insert images slow downs the ELOG, posted by Andreas Luedeke on Sat Sep 12 19:19:02 2020
|
I found the most limiting factor of ELOG to be the file access. ELOG stores all entries in files and therefore has a lot of disk access.
We found that an AFS directory for ELOG is unusable. We tried to store our logbooks on NFS, and it was barely usable but slow. Now we use a local disk on the server, that works fine.
If you want to speed up ELOG the best approach is a dedicated server with a local SSD storage.
| Zbigniew Reszela wrote: |
|
Dear all,
First, many thanks for creating and sharing this great tool which is ELOG! Our users are very happy with it!
I have few questions about inserting images into the entries.
From time to time our users insert them directly in the editor what leads to encoding the whole image in the HTML log file and the images does not appear in the attachments list. Saving and further editing of such entries slows down the whole ELOG server which uses 100% of CPU.
I'm not sure how they do it Ctrl+C & Ctrl+V, drag & drop, etc.. What I know is that if they add it using the "Insert image" action in the editor there are no problems and the images are properly listed in the attachments.
I read in the docs:
uploading or downloading an attachement file is a single request, and causes the entire file to be loaded in server memory while the request is being processed.
This is not normally a problem for the sort of short, text-mode entries ELOG is designed to support. However, if a user starts to upload or download a large attachment file (or image) over a slow link, all other users on that ELOG server will have to wait for that transfert to finish before they can access any logbook on that server. This is why there is a low limit on the size of attachments, and why ELOG should not be used to distribute large files under intensive multi-user conditions.
but I think this is not our case. Here I talk about wrongly inserting a single image of 700KiB.
So, I'm asking:
- Is the behavior that we observe something already detected? If yes, which are exactly the wrong ways of inserting the images?
- Is it fixed in newer ELOG versions?
- Is it possible to disable the wrong ways of inserting the images in order to avoid such problems?
Many thanks in advance for your help!
|
|
|
Re: Insert TimeStamp not working, posted by Stefan Ritt on Thu Jul 30 11:10:59 2015
|
That problem has been fixed this week by this commit: https://bitbucket.org/ritt/elog/commits/5a8547bd995d88d7e314de30ee4bce71aa129c00
Please upgrade to the current revision from the bitbucket repository and recompile elog.
| Luca wrote: |
|
Hi,
I have an eLog logbook installed on my machine.
If I click on the INSERT TIMESTAMP botton in this post a Timestamp of the kind "Wed Jul 29 23:09:15 2015" is added.
When I do the same (with the same browser) on my logbook, nothing is added. Ideas about what might be causing this?
Regards
Luca
|
|
|
Re: Inline images URL not working, posted by Stefan Ritt on Thu Mar 2 07:15:27 2006
|
| Alexandre Gauthier wrote: | Whenever I try to insert an inline picture by using the elog:1741/1 paths with ELCode, the link becomes "logbookname2/1" (Where logbookname is the name of my logbook) and hence, doesn't work. I recall that it worked once. The image did not display, but the URL seemed correct... |
The problem has been fixed in version 2.6.1-3, so just upgrade.
| Alexandre Gauthier wrote: | | EDIT: i inserted a space in the elog URL above because regardless of the code brackets, it would still get interpreted. |
You have to put a "\" in front of everything which should not get converted into a link, so elog:1741/1 does not get interpreted. |
Re: Incrementation of attribute is not functioning, help needed to fix this., posted by Stefan Ritt on Mon Feb 2 09:46:24 2009 
|
| Guido Böing wrote: |
|
I appear to be doing something wrong or not..
In my configuration I use an incrementation of a certain attribute (Melding)
For some weird reason it won't increment in this place, while it does in another place...
Below is my configuration (at least the part that gives me headaches..)
[Onderhoud Diversen]
Theme = default
Attributes = Melding, Auteur, Type, Planning, Categorie, Status, Onderwerp
Options Type = Preventief, Regulier, Nav Storing, Overig
Options Categorie = SensorProbes, Overig
Options Status = Wachtend, Gepland, In behandeling, Update, Afgerond
Type Planning = date
Extendable Options = Categorie, Status
Required Attributes = Auteur, Type, Unit-Lokatie, Status
Page Title = ELOG - $onderwerp
Reverse sort = 1
Quick filter = Date, Type, Status
Preset Melding= DIVOH: %d%m%y-####
Subst on edit Auteur = $long_name
List Display = ID, Melding, Datum, Status, Auteur, Type, Planning, Categorie, Onderwerp
Summary lines = 0
Display Email recipients = 0
Email All = aapie@sukkeltje.com
Use Email Subject = $Melding, $Onderwerp - $Status
Style Status In behandeling = background-color:red
Style Status Update = background-color:orange
Style Status Afgerond = background-color:lime
Login user = person1, person2
|
I tried your configuration and got the attribute incrementing correctly:
so I'm a bit at a loss, too. Maybe your browser caches the old page, so try a "Reload" on your browser or clear your cache. Maybe your logbook contains some weird entries which make the incementing break. Try this configuration with an empty logbook. Certainly the configuration options are correct. |
|