I’ve been told that the new 13/14 SKIF software is likely to be SQL based, rather than Access.
We are advised not to put the current LIS onto a network but I was wondering if there would be the same limitations with the SKIF being SQL?
Would we be able to put it onto a network so it could be accessed by multiple people instead of having it as a standalone piece of software on individual PCs?
SarahApril 24, 2013 at 3:45 pm #1034
As with the Learner Information Suite, the replacement application is intended to be installed and run manually within a standalone physical PC environment only.
The back end may be on local SQL server and the front end may be a standalone application with the same requirements as the current LIS, have you considered the problems of overwriting your data if you try and use it for multiple people.April 24, 2013 at 5:02 pm #1035
We have in the past put a copy of LIS onto an Application Server so that others can run the reports but we only had a single point of data entry. We have subsequently abandoned that as we now import the ILR Export data into our own MS SQL database (with some quite complex conversions along the way to cope with the annually changing table structures) for wider internal reporting. Moving to MS SQL is a good step forward and I think it would be useful to have the option to use a network full MS SQL server, if available, or a local MS SQL Express on a PC. The advantage of using the full MS SQL server is that the data will then be backed up with the main system backups, but there is still the option for those who don’t use MS SQL.
I hope that in the ongoing design of SKIF you are going to reduce the number of changes to data tables year on year, as this has resulted in a lot of effort being spent locally in re-writing our internal analysis reports. Some of the column changes have been just name changes which is really frustrating. So my plea is to keep the end user in mind and how they might be using the exported data.
TonyApril 25, 2013 at 9:32 am #1036
SKIFS can be installed on both physical and virtual machines as a standalone installation. Each installation can be configured to use a SQL Server instance installed on a network (SQL Server 2008 R2 or 2012). Alternatively each installation of SKIFS can use a local version of SQL Express that is included as part of the application install process if you chose to use a local version.
It should be noted that if SQL Server is used with multiple installations of SKIFS, each installation will have it’s own database instance within SQL Server.
All data stored in SQL server relating to a user’s installation will be solely accessible by that user. Therefore, users will not be able to overwrite each other’s data when using a networked SQL Server setup.
Over the coming weeks we will be publishing further details on the features/functionality of 2013/14 SKIFS software.
The Data ServiceApril 25, 2013 at 10:33 am #1037
I have been told by Hardip that the replacement LIS will only work with SQL 2012 (because it is exploiting functionality not available in earlier versions) and that is why it will not work on Windows XP, but you have intimated that it will work on SQL 2008 R2 which does work on Windows XP – can you clarify this point, please?
Also, crucially for many people, I have been led to believe that the new LIS will still export LIS_EXP.mdb in Access format so that can still be integrated as before for those that use it (eg PDSAT). Please can you confirm that this is a permanent feature of the new version?
With regard to the other question about installing it on a network, I have also been asking the same question for some time and have been told that it will probably work, but that the Data Service will not be able to support it as there are too many platforms/choices out there, so they will only support the very obvious, simplest ones, like Windows 7 or 8 standalone installations.
With regard to Tony’s dilemma over field name changes, I do hope that field name formats are being properly standardised. When XML was first introduced some of the table names had an underscore in and some did not and likewise the field names – for instance in one table it might be fielddesc and in another field_desc which was thoroughly infuriating and, like Tony, I have some custom code to handle these illogical occasions. However, as a suggestion, why not run your reports on SQL Views and then the reporting suite can run every year and all you have to do is modify the SQL View according to the academic year? If you have the academic year stored somewhere or can calculate it then you can even have a CASE statement in SQL so that the same View can work over multiple years.
CasparApril 29, 2013 at 3:52 pm #1059
You must be logged in to reply to this topic.