Opened 9 years ago

Closed 9 years ago

#260 closed defect (fixed)

Can't save imported legacy data to server

Reported by: rcarney Owned by: dzollars
Priority: critical Milestone: future
Component: ultrascan3 Version:
Keywords: Cc:

Description (last modified by demeler)

I just checked your database with the latest linux version (1135). After entering your DB credentials I was able to successfully upload some intensity data to your database. I suspect that either there was a change in the database credentials (which I will send you in a separate message) or in the ultrascan code. I will place a 1135 binary release in the download area for the US3 website.

Attachments (1)

mySQL_error.png (14.1 KB) - added by demeler 9 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 in reply to: ↑ description Changed 9 years ago by demeler

  • Description modified (diff)
  • Owner changed from bdubbs to demeler
  • Status changed from new to assigned

Replying to rcarney:

In US3 linux 1128 and 1114 release, after converting Legacy Raw Data and attempting to save, the first box says "success...files written" but when it attempts to save them to the server it returns the error:

"Problem saving experiment information... MYSQL Error:MySQL: no rows returned (-1)"

comment:2 Changed 9 years ago by demeler

  • Resolution set to worksforme
  • Status changed from assigned to closed

comment:3 Changed 9 years ago by demeler

Yes it looks like I'm still having the same problem even with the 1138 build. (didn't have to g
et a new license).

The database connects successfully, but I still get the same error (attached).

-randy

comment:4 Changed 9 years ago by demeler

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:5 Changed 9 years ago by demeler

  • Owner changed from demeler to dzollars
  • Status changed from reopened to new

Changed 9 years ago by demeler

comment:6 Changed 9 years ago by demeler

I am not sure what is causing this problem, we'll have to ask Dan to take a look. Today is a holiday in the US, Dan will be back on Wednesday.

comment:7 Changed 9 years ago by demeler

Brent Halling reported a similar issue and wasn't able to connect.

comment:8 Changed 9 years ago by dzollars

This is a confusing error message. It isolates the code where it must have originated, but at the same time doesn't give us enough information about the circumstances. However, there aren't many ways in which the investigator can get the -1 error back from the stored routines, so that isolates it too.

Based on the routines that I isolated, I suspect that this may have to do with the instrument operator selection. Let's say that the list of authorized instrument operators has changed, or that the experiment originated on disk and the operator was never actually chosen. What is happening, I think, is that the stored routine is rightly refusing to store this record but is not giving us the right error message so that we understand why.

Anyway, I have made a couple of changes to the error reporting in that routine, which I hope will identify the problem better. In any case, the investigator should try editing the run information again and verify that an operator from the database is selected. Then he should try to save the experiment again.

Let's keep this ticket open for a little while and see if we can witness the changes.

comment:9 Changed 9 years ago by dzollars

  • Status changed from new to assigned

By the way, this is a change that shouldn't require updating software versions. Just try to save a new experiment and see what happens.

comment:10 Changed 9 years ago by demeler

  • Resolution set to fixed
  • Status changed from assigned to closed

Access to database now functions reliable. Ticket will be closed and can be re-opened if issue resurfaces.

Note: See TracTickets for help on using tickets.