SuccessMaker destroys it's own records

[calikit]

Hi everyone. I've been lurking for a bit, but now have a problem I could use some advice for.

 

My school runs SuccessMaker (not sure of the version sorry) in a pod of about 30 PCs. As the PC tech, this unfortunately falls into my jurisdiction.

 

Our problem is that SuccessMaker will sometimes just eat all of it's enrollment records. I'm informed this happens when someone doesn't log out properly. The next class to come in will then get "Student not enrolled" errors when they try to start the program. I then have to restore everything from the backup, which is thankfully done daily. At the moment, I'm doing this two or three times per week.

 

WTF? How this happens at all just boggles my mind. Apparently, we had SuccessMaker come and look at it (at ridiculous cost to our Learning Support Dept) and they blamed our network. This seems unlikely because it has it's own closed network with no internet and a dedicated server. Sounds to me more like some rubbish database design that lets it's clients have way too much access.

 

Has anyone else had this issue? Did you find a solution for it? Any tips for getting more cooperation out of the SuccessMaker people?

 

Thanks in advance for your help and/or commiseration.

[p858snake]

WTF? How this happens at all just boggles my mind. Apparently, we had SuccessMaker come and look at it (at ridiculous cost to our Learning Support Dept) and they blamed our network. This seems unlikely because it has it's own closed network with no internet and a dedicated server. Sounds to me more like some rubbish database design that lets it's clients have way too much access.

I would be looking/asking for a report stating as to why it's caused by your network.

[Duke5A]

What version of Success Maker are you running? It's been around for a while and has gone through some big changes. In the previous district I worked at we had a web based version that was hosted internally, and in the current district I'm at we're running an ancient version that requires a client to be installed on the workstations. The old one is what I'm most familiar with as I just had to migrate it from multiple servers back to a single. It uses a SyBase back end, and can be a pain in the neck.

[calikit]

So I've inquired with all the various points of contact and all they can tell me is that a SuccessMaker guy came out, spent many many hours looking at it, then charged us $150 for each of those hours and declared it was the network. There isn't a report anywhere and the person who worked with the technician was a teacher.

 

As for the version, it seems to be version 5. We've had it nearly ten years apparently. This thoroughly predates me, so I've no idea how long this has been happening or whether it did it on the original computers or anything like that. Nobody seems to know.

[theriver]

I last worked with Successmaker about 11 years ago (can't remember the exact version) and while I don't recall this exact error it sounds like it might be related to one that was a problem for us too. Or it might even be the same one, it was 11 years ago now after all!

 

If I recall correctly (it was 11 years ago - did I mention that?) the app monitored its own concurrency by having a centralised licence file maintained by the clients. This was a file on the server that contained the total number of authorised users, and when a user logged in their client would open the file and deduct one from the number stored in it. Thus when all users were logged in the figure would be 0, and nobody else could use the application. When a user logged out the app opened the file and added one back to the available licence count.

 

The problem came when users didn't log out properly, or as far as the app was concerned didn't (i.e. turned off machine, network problem etc.), because the licence never got handed back in. And of course this happened a lot, because out of a class of year 7s at least one or two each lesson is just going to hit the power button, and this meant that we would often have subsequent lessons where one or more students couldn't log in. Disruptive.

 

Once we realised that this was how the application was working, I made a copy of the file in question and set up a scheduled task on the app server to delete the current one and copy the copy into its place. This ran every break and lunch time and after school, and 'fixed' the problem.

 

As I've said, while this sounds different to the problem you're experiencing, given that you've mentioned log out as a trigger then this could be it or a similar mechanism in play - depending on how gung-ho you're feeling I'd monitor the files on the server and see if you can identify which change and if any are clearly serving a similar function (as opposed to being, for example, the data files (!)).

 

Do take a backup first ;-)

 

Also, I'd demand a written report from the support company, or at least to get the ball rolling a request that their tech talks to someone technical at your end - "it's the network" is either a garbled message from your colleague or a cop-out from the support guy.

 

Good luck.

[calikit]

The version we use definitely uses the license checking method you've described (as demonstrated by a different error, seen when cables fall out etc), but I'm not sure how that could explain the software insisting that the students aren't enrolled. Also, this occurs when (allegedly) just one student fails to log out correctly and affects all machines running the client. We've got 30 licenses.

 

On the other hand, could the unreleased licenses be causing the clients to be blocked from accessing the database? Since I'm not called until after everything is broken, perhaps it's happening more than once or twice per session and the teacher doesn't realise or it's building up over time with nobody noticing when not all computers are in use.

 

In your case, were students getting the same error "student not enrolled" when the system ran out of licenses?

[theriver]

I'm sorry, I really can't remember the exact message we used to get.