Fixing a SQL Server Job Status Without Restarting Services

SQL Server logo

Yesterday morning I received notice that a SQL Server job for an application I support that normally ran fairly regularly was not working. This job was not kicked off by a manual schedule, but was called from elsewhere.

I was able to run the job manually with no problem at all. Nevertheless, the job did not start running “automatically” as expected. After some digging, I found out that the job was kicked off in a database trigger on INSERT.

The section of code that kicked off the job looked like this:

SET @JOB_NAME = N'My job name'; 
		select 1 
		from msdb.dbo.sysjobs_view job  
		inner join msdb.dbo.sysjobactivity activity on job.job_id = activity.job_id 
			activity.run_Requested_date is not null  
		and activity.stop_execution_date is null  
		and = @JOB_NAME 
		PRINT 'Starting job ''' + @JOB_NAME + ''''; 
		EXEC msdb.dbo.sp_start_job @JOB_NAME; 
		PRINT 'Job ''' + @JOB_NAME + ''' is already started '; 

So this code should only return a row (and prevent job execution if the job is already running. The job was not running, and yet a row came back saying that the job had started two days before and never finished.

It just so happened that the SQL Server cluster had to be rebooted at just that time. The job appeared to be running, but was not.

The first solution: Restart the SQL Server Agent. This had no effect on the sysjobactivity table.

The second solution: Restart the entire SQL Server instance. This was not done, due to critical operations at work.

What else could be done?

Manually updating the table to reflect that the job was no longer running!

DECLARE @job_name VARCHAR(2000) = 'Your job name'; 

DECLARE @job_id uniqueidentifier =
    (SELECT job_id
    FROM msdb.dbo.sysjobs
    WHERE NAME LIKE @job_name); 

UPDATE msdb.dbo.sysjobactivity
SET stop_execution_date = GETDATE()
WHERE job_id = @job_id
AND start_execution_date =
    (SELECT MAX(start_execution_date)
    FROM msdb.dbo.sysjobactivity
    WHERE job_id = @job_id
AND run_Requested_date IS NOT NULL  
AND stop_execution_date IS NULL);

EXEC sp_stop_job @job_id = @job_id;

Running this block of code enters a time (now) for job execution end, and also manually sends a job stop command in case the job had started in the meantime.

After this, the trigger worked as expected!

Widgets in Temenos Quantum Visualizer for iOS and Android

Temenos / Kony Quamtum Visualizer

Over the last few weeks, I have been building an application using Temenos (formerly Kony) Quantum Visualizer version 9. This app will eventually be pushed to both Apple and Android phones and tablets, which is the main reason someone would use Visualizer instead of developing natively with XCode and Android Studio.

In theory, the JavaScript code written in the Visualizer IDE will result in the same UI on both the iOS and Android platforms, but that isn’t always the case.

For the first time, I got an actual JavaScript error on the Android app, whereas the iOS app worked perfectly. Apparently, Android isn’t as forgiving when accidentally leaving out the “new” keyword when instantiating a widget – in my case, a RadioButtonGroup. (The error I got on the Android side was “invalid operation : trying to create object without ‘new’ keyword”.)

The RadioButtonGroup widgets, when set in Toggle mode, are rendered differently on iOS and Android. That wasn’t really a problem in and of itself. The problem was that the iOS widgets looked good and took up the entire width of the parent container (a FlexScrollContainer), and the Android screen had the radio buttons bunched up on the left side of the screen.

RadioGroupButton differences on iOS vs. Android

For whatever reason, the Android app required that the hExpand property be set to true, and it didn’t matter on the iOS version.

The moral of the story: If your UI looks different in unexpected ways on one platform, it probably will require explicitly detailed widget property attributes to make them look more similar.