Check for update would be a good idea
However, it could be done as Check for update now, or Check for update in a
week or next time when EpiData is launched.
Kind regards
Tieble
On 22 November 2014 at 18:00, <epidata-list-request(a)lists.umanitoba.ca>
wrote:
> Send EpiData-list mailing list submissions to
> epidata-list(a)lists.umanitoba.ca
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.umanitoba.ca/mailman/listinfo/epidata-list
> or, via email, send a message with subject or body 'help' to
> epidata-list-request(a)lists.umanitoba.ca
>
> You can reach the person managing the list at
> epidata-list-owner(a)lists.umanitoba.ca
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of EpiData-list digest..."
>
>
> EpiData-list mailing list
> ___________________________________
>
> Today's Topics:
>
> 1. Re: automatic warning/information on versions ?
> (epidata-list(a)lists.umanitoba.ca)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 22 Nov 2014 13:02:09 +0100
> From: epidata-list(a)lists.umanitoba.ca
> Subject: Re: [EpiData-list] automatic warning/information on versions
> ?
> To: epidata-list(a)lists.umanitoba.ca
> Message-ID:
> <
> CAGCnkGU66_DiM0mdvC0ruoaNuSUndFgMXdjQ5EgXGdYBQR6n4Q(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Jens
>
> This option sound good for me :)
> As ouy say, many users are not listening the list.
>
> Regards
> Gilles
>
>
>
>
>
>
> *Dr Gilles DESVE Epiconcept consultant Mobile : 33 (0)6 87 73 50 88 Fax :
> 33 (0)9 72 12 20 81 *
>
> 2014-11-20 23:51 GMT+01:00 <epidata-list(a)lists.umanitoba.ca>:
>
> > I would like this option, Jens. It is very commonly used - along with a
> > preference to NOT check for updates.
> > Jamie
> >
> > On Nov 20, 2014, Jens wrote:
> >
> > > We could therefore consider to have the end user decide an option
> saying
> > "check for new version every x days" (e.g. x could be 7). Please give
> > viewpoints and considerations on this.
> > >
> >
> > _______________________________________________
> > EpiData-list mailing list
> > EpiData-list(a)lists.umanitoba.ca
> > http://lists.umanitoba.ca/mailman/listinfo/epidata-list
> >
>
>
> ------------------------------
>
> ________________________________________
> EpiData-list(a)lists.umanitoba.ca
> http://lists.umanitoba.ca/mailman/listinfo/epidata-list
>
>
> End of EpiData-list Digest, Vol 132, Issue 7
> ********************************************
>
With development of the software new versions are released every time
development has reached a certain point.
It can be annoying to be informed very often about new releases from
software, since this takes time and processor and sometimes also for
users costly Internet connections.
On the other hand we know that some users run into problems due to NOT
having updated to a newer version in which a given problem was solved.
We could therefore consider to have the end user decide an option saying
"check for new version every x days" (e.g. x could be 7). Please give
viewpoints and considerations on this.
Also I noted today that some "semi-comercial" sites most likely running
from the advertisements on that site offer download of the software .
The webplace in question have been contacted by me. If we have automatic
checking with reference to the true EpiData website, that problem would
be minimized .
Is this a desired option or does it work fine with the users getting
information from this list in general ? . We know the list have about
700 persons "listening", but the number of actual users is very much
larger and these other users do not easily know that there is a new
version around.
regards
Jens Lauritsen
EpiData Association
The next test build of Manager and EntryClient will be released rather soon, but not this week.
The aspects we are working on - apart from securing stability - regards handling complex relational entry.
To do so properly and with sufficient stability accross projects, operating systems and countries we need to be very focused on the niche in which EpiData Software is working.
This demands some simplifications, which will be seen in the next test release:
1 backup after entry:
Until now the backup files (e.g. Clinical_Example_2014-10-28_0.epz) would be placed in the "home" dir of the EntryClient user (e.g. for user jla = c:\documents and settings\jla\documents\EpiData\backup) . This resulted in a complex demand to handle a large number of combinations of operating systems and user rights.
>From now on the backup file will be placed in a subfolder to the folder where EntryClient opens a given epx/epz file for entry. If the user want the backup placed in another folder this must be defined with a startup option.
2 Which status of addition/editing of records in EntryClient
Aspects of this has been defined in preferences for EntryClient.
>From now on EntryClient is assumed to be adding records to projects always. But obviously in such a way that if a given dataform has a key and that key is typed in, then the user will be informed and given the opportunity to jump to the relevant record.
3 For related systems the order of activation of "child" forms is part of the project epx file. Not a "preference" setting.
This might seem a bit technical, but is needed in order to make sure that the software creates consistent data and also that we can complete the work within the funding of the project. Funding is always an issue for this and other development projects.
Comments to this or other aspects of development are welcome.
regards
Jens Lauritsen
EpiData Association
HI,
I am very new to EpiData and am looking to use it for a Study which will require a relational database ie one study participant with multiple visits and tests
Am I right in interpreting that only EpiData Classic Entry 3.1 is the only software that I can currently use.
I have had a trial run using EpiData Manager 2.0.0.1 and it seems perfect for our study. Is it worth holding off setting up my database for the beta release of this version? When is it likely to be released?
Kind regards,
Emma
Emma Jamieson
ORCHID Study SouthWest Coordinator
RCSWA - UWA
Building 3, Edith Cowan University, Robertson Drive,
PO Box 412,
BUNBURY WA, 6230
Ph: +61 8 9722 0510
M: 0478 193 116
F: +61 8 9722 0555
-----Original Message-----
From: epidata-list-bounces(a)lists.umanitoba.ca [mailto:epidata-list-bounces@lists.umanitoba.ca] On Behalf Of epidata-list-request(a)lists.umanitoba.ca
Sent: Friday, 7 November 2014 2:01 AM
To: epidata-list(a)lists.umanitoba.ca
Subject: EpiData-list Digest, Vol 132, Issue 3
Send EpiData-list mailing list submissions to
epidata-list(a)lists.umanitoba.ca
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.umanitoba.ca/mailman/listinfo/epidata-list
or, via email, send a message with subject or body 'help' to
epidata-list-request(a)lists.umanitoba.ca
You can reach the person managing the list at
epidata-list-owner(a)lists.umanitoba.ca
When replying, please edit your Subject line so it is more specific than "Re: Contents of EpiData-list digest..."
EpiData-list mailing list
___________________________________
Today's Topics:
1. Status testversions of 2.0 Manager and EntryClient
(epidata-list(a)lists.umanitoba.ca)
----------------------------------------------------------------------
Message: 1
Date: Wed, 05 Nov 2014 21:13:16 +0100
From: epidata-list(a)lists.umanitoba.ca
Subject: [EpiData-list] Status testversions of 2.0 Manager and
EntryClient
To: EpiData-list(a)lists.umanitoba.ca
Message-ID: <545A84DC.30204(a)epidata.dk>
Content-Type: text/plain; charset=utf-8; format=flowed
The status and reported problems in the development of v2x of Manager and EntryClient is such that:
a. Basically we find rather stable function with few access violations and remaining major problems b. We found reason to further change the xml structure contained in the epx file when dataforms are in a relational structure. This means that examples you have worked with in the testing of v2x might not work, when we release the next test build.
c. A number of minor points have been found in various parts of the system. Mostly these were of text formulations, which had not taken the relational dataform aspect into consideration.
I expect that the next test version will be moving from experimental level to pre-release level. This is an indication that we are approaching something which in the end will be applicable for true data entry and documentation.
Further thoughts and reports of or examples of malfunction are highly appreciated.
Jens Lauritsen
EpiData Association, Denmark
------------------------------
________________________________________
EpiData-list(a)lists.umanitoba.ca
http://lists.umanitoba.ca/mailman/listinfo/epidata-list
End of EpiData-list Digest, Vol 132, Issue 3
********************************************
Dear EpiData users and experts
I am trying to merge
two files with different number of records and fields!
The first file (intake) contains 1433 records and there is 21 fields
in each record. The second one contains 1301 records and and each record
contains 31 fields. Each one of the 1301 record has a corresponding record
in the first file (same code). I would like to merge the two files, based
on the code, so that I have a third file with 1301 records and 52 fields.
I tried to use the merge function in EpiData Entry, but it didn't work (the
product was a file with only 47 fields instead of 52 ). I must say that
some fields in the two files have the same name-can this be a reason for
not merging these fields?
Your help will be highly appreciated
Best,
MK
The status and reported problems in the development of v2x of Manager
and EntryClient is such that:
a. Basically we find rather stable function with few access violations
and remaining major problems
b. We found reason to further change the xml structure contained in the
epx file when dataforms are in a relational structure. This means that
examples you have worked with in the testing of v2x might not work, when
we release the next test build.
c. A number of minor points have been found in various parts of the
system. Mostly these were of text formulations, which had not taken the
relational dataform aspect into consideration.
I expect that the next test version will be moving from experimental
level to pre-release level. This is an indication that we are
approaching something which in the end will be applicable for true data
entry and documentation.
Further thoughts and reports of or examples of malfunction are highly
appreciated.
Jens Lauritsen
EpiData Association, Denmark
Hello List,
As a District Medical Officer, I will have to prepare for Contact tracing
and risk assessment/managing the follow-up of contacts if an unsuspected
Ebola case should surface in my community.
I have started to think of a call center / health care registration system
in EpiData Manager with relate feature: One event/Index case, several
contacts with contact details, and follow-up details of contacts. In the
event that one of the contacts should develop symptoms, then the secondary
case´s contacts will have to be traced. The design of the system certainly
needs some consideration.
This is a global concern, and I imagine several organizations probably
already have made or have plans to develop such a system. EpiData´s
share-friendly approach should be ideal under current circumstance. ECDC
have already done so for food/waterborne outbreak investigation.
1. Anybody already made a system, wiling to share?
2. Any major Organization seeing the benefit of same-format reporting, and
willing to support development of system/templates?
3. I assume that final release of ED 2.0 with relate feature is imminent. I
therefore start to work on a functional but simple local system anyway, and
will seek advice from the list as needed. Where I am right now, I struggle
to carry the content of more than one unique key variable over from the
parent to the child record.
Any comments?
Best regards,
Vegard Hoegli
District Medical Officer
Skien, Norway