Whenever I want to add a patient gene variant, I always have to first check whether or not that variant already exists in the database. That usually is not a problem, but external submitters do not always check properly and it can lead to duplicates: the same variant is in the database twice and with different IDs. Would it be possible for LOVD to monitor the variant description and advise the submitter if that variant is already in the database?

Note from developers: This is about a bug in LOVD, where when adding a variant that is already in the database to an existing patient, LOVD does not check in the correct way if the variant already exists and may report that the variant already exists for the patient, while it does not.

When login/password entered by an admin or a submitter using Firefox or Camino, it bounces back to the login page. Each time.

When Safari is used, it goes well.

Is my installation bad? Because I am pretty sure that your high quality tool works with free browsers world, so have you ever heard about that problem?

Back in June, a bug was discovered in the "Reference Sequence Parser" script and it was subsequently fixed. The script had produced the expected output files but the data were incorrectly formatted. Today, I used Reference Sequence Parser again (for the first time since June) for the same gene as before and many error messages were generated this time.

I had selected the option of "overwrite it" to allow the old files to be overwritten if they existed, but the script was unable to do so because the permissions on the files (-rw-r--r--) did not allow it. Deleting each of the old files did then allow the script to create the new files.

Perhaps the script should create the files with the permissions -rw-rw-rw- to allow old files to be overwritten.

On Windows using Internet Explorer 7, there is a problem when searching through the variant lists.

If I type a query string into any of the search boxes that are displayed when the "Search unique variants" button is pressed on the "Variants" tab, the query is not executed when I press the Return key and the Windows "Default Beep" sound is played. A click with the mouse then activates the search and the expected results are returned. The same happens for "Full database search".

I have confirmed this behaviour on another computer which is also running Windows XP and IE7. My computer is running SP2 and the other may be running SP3.

There are no problems with Firefox.

When unpublished data are submitted directly to my databases I have to make the assumption that the submitter has obtained informed consent from the patient or the patient\'s guardians to do so. It would be desirable that there be a check box on the submission form, for remote submissions, to confirm that ethical consent had indeed been obtained. Failure to check the box would block the submission.

LOVD provides the ability to create links to dbSNP and OMIM and, by default, these two links are active in the Patient/Reference column. However, dBSNP and OMIM entries are properties of the variant rather than the patient. All patients who harbour the same variant should be linked to dbSNP, but by way of the variant that they share in common, not individually through the Reference column.

It would be useful to have decicated dbSNP and OMIM columns associated with Variants. The input fields would only require appropriate DBSNP or OMIM numbers to be inserted; nothing else.

I guess that I could create custom Variant columns myself and then make the dbSNP and OMIM links active in these columns. However, that\'s an untidy solution that perhaps might have unwanted consequences for data exchange. A field containg only a dbSNP rs number is easier to exchange that one that contains code for a link.

It is awkward to create a patient record with variants in different genes. Creating the record for the first variant is straightforward. If you then try to create a second variant immediately, LOVD assumes that the variant must be in the same gene. Their is no obvious way to select another gene before the patient details are entered. The workaround is to only enter the one variant for the pateint and then to finalize the submission. Once that\'s done, you can change the gene and create the variant entry in that gene. When that\'s complete you can then attempt to use the \"Using an existing patient\" button. The problem is that you then get prompted to enter the ID for that patient and there is no way to look it up. You have to have written it down (or have a photographic memory).

The ideal solution would be the ability to change gene, as necessary, for each additional variant to be recorded for a patient. Alternatively, there should be the ability to look-up the patient.

During variant entry, there is a prompt to the left of the variant ID data-entry box. In early builds of LOVD 2.0, the prompt displayed the maximum ID already in use. In more recent builds it\'s the next available ID (First ID free:) that\'s displayed - altogether more sensible. Could the logic now be extended to providing a button to enter that ID into the field, so replacing copying and pasting?

I have found this to affect the auth log entries and also \"Allowed IP address list\" in Manage users security settings. The IP address of the user is not correctly identified. In my case it is not my IP address instead a server IP. Looking at the auth log entries in event \"AuthLogin\" the same IP address address is reported for every event. the function of IP security does not function correctly because the IP address detected is not correct, so it does not block.

There is a modification that we made in one line 269 the inc-init.php file that allows our specific socket configuration read from config.ini to be recognized. The specific modification is adding a \":\\/\" in the line \'/^[0-9a-z][-0-9a-z.]*[0-9a-z]$/i, to make it \'/^[0-9a-z][-0-9a-z.:\\/]*[0-9a-z]$/i\', which allows for more flexible configuration.

refer to out notes at
http://bmi.cchmc.org/resources/software/lovd/overview/?searchterm=lovd

If you add this change to next version, we don\'t have to change it every time we do an update.

Thank you