SkywOrca

You would also need to install SSRS on the server in order to get Report Builder to work! If memory serves, that can be a hassle in itself if it wasn't installed when the server was originally deployed as it won't allow you to use default configs when adding it to an extant server.

So if your phone started to bend in the first few weeks, but not so badly that you've gone over the 45° (or whatever!) that they specify as a minimum bend to warrant a replacement they send you away. If it was bending that much in the first few weeks there's nothing to say that the phone won't then continue to bend over the next few weeks/months, but because you had it checked out before it was "too bent" they refuse to ever replace the defective device?? Great example of customer service there - thought that was what Apple were renowned for?

Just a quick note to point out that there is an issue with using ePortal under IOS8 whereby the menu navigation bar isn't being displayed. Advanced are investigating the issue. https://s3.parature.com/link/portal/5527/5565/Article/5928/Menu-bar-does-not-show-for-iPads-running-IOS-8

Got things working as normal again now, thanks Zero!!

I noticed issues with Chrome this morning, whilst I was trying to work out if the theme issue I raised was due to my Firefox profile getting corrupted again. I was just getting Page Unresponsive errors, however. They seemed to sort themselves out not long after.

The question is which version of the Hotel did they base this off? The layout changed in almost every episode, oftentimes to the point where it would have been cheaper for Basil to knock the old building down and rebuild from scratch!

Cool, thanks Zero - I realise you have a lot on right now, so I'm happy to "suffer" along with the tabbed layout!

Actually, further testing would suggest that any theme other than the standard V5 Blue theme are similarly bugged.

I think there are some issues with the No Tabs theme. The page layouts are completely messed up!

The kittens one is referring to the coefficient of friction, often quoted with the greek letter mu (mew). However, the joke should read that the one with the smallest mew falls off first, since that indicates the one that is the most slippery. Loved the Seuss poem, btw!

I'd definitely agree with this, nothing teaches you how to code better than working on a problem, and better still if you can find a project that already works that you can tinker with (in a dev environment, don't muck about with production until you're confident!). You could also check out Code Academy - I did a few of their courses a couple of years ago and they worked really well, javascript is a pretty good beginners language and the online IDE at Code Academy is a great way to tinker about with the examples and get to grips with how it all hangs together.

The simplest way of getting data out of Advanced Learning's Facility system (Serco no longer have any involvement with the product) is by creating a report and using the export option on the generated data. You can even set up the report to have csv as the default export method. You should be able to get data out from a report in almost any format you need (subject to some limitations of the reporting engine built into the product). You haven't specified what sort of format you're expecting to get the data in, but you should be able to create reports that display the data by day or session, counts or percentages, groups/years/individuals - in fact almost any format you might need.

The best way to put your mind at rest on this would be to check the size of the ldf files for your databases. If the LA solution is not correctly backing up or checkpointing the transaction log then these ldf files (these are the files that contain the transaction log itself) would just keep on growing. It would depend on how long the backup solution has been in use for and how much data gets changed in your database as to how big "big" would be, but as a rule of thumb if it's bigger than your database file it's probably not being dealt with correctly. In this case, as others have suggested get back to your LA and report the large transaction log file as an issue and get them to fix it. Also, even with a database that is in a Full recovery model you can still restore (to the point at which the backup was taken) even without having taken a transaction log backup alongside the main backup, but you would lose differences that the transaction log would have been storing for you, so even if the setup was not correct you wouldn't be completely unprotected. The problem with the Full recovery model is the potential that your transaction log files grow out of control and either fill your disk (very bad) or hit the maximum file size limit set on that file (also pretty bad). The result of this would be that the SQL server could no longer add or update data in your database, which would generally mean that your MIS system would start spitting out a whole bunch of errors - I'm not sure exactly which errors SIMS would give you at that stage, but you could probably expect to see almost anything and it would likely be related to the lack of tlog space. Full recovery is safe so long as your transaction log backups continue to happen, and so long as your on top of checking your backups you'll probably spot an issue with it pretty quick.

I'd agree with advising caution here. You can pretty easily check if the databases are in full or simple recovery mode by checking the Properties of the databases, Options tab and the Recovery model setting. If this is set to anything other than Simple you might need to contact your LA and get them to double check the configuration of your backups as you'd be likely to run up against a transaction log that either fills your disk or hits its maximum file size, both of which would result in your system no longer recording new data. Given that it was your LA that set up your backups they should be responsible if there is an error in the config, so get them to do the donkey work of fixing it.

Given that we're so close to the end of the academic year, you're probably best just calling the LA for a new UPN each time you need one. From September onwards your UPN serials will reset so you'll be able to generate them again as normal. The only other alternatives would involve removing UPNs from pupils with high order serial numbers in order to clear some room in the series, but this would involve getting any UPNs that had now gone up the chain or out to other schools changed to new values to maintain consistency - certainly more work at this stage than getting the LA to issue you with UPNs from the pot that they know are unused.

UPNs are generated by the system using a strict set of rules defined by the DfE. It uses various pieces of information to create the UPN including DfE country code, school code, a cohort identifier and a three digit index unique to the pupil which starts at 001 and can run up to 999. This information is then passed into another algorithm that generates the letter code which acts as a verification code to ensure that the UPN has been generated correctly and should be unique (flipping a single digit in the number will invalidate the checksum letter). Facility keeps track of which UPN's have been issued by inspecting the current highest order serial number for your combination of county code, school code and cohort number, then adds one and generates the number from there. What this means is that it is possible to generate UPNs that skip over index numbers from this sequence, and this is what has happened in your case. You already have a pupil that has used the 999 serial number for this cohort, so the system will no longer be able to generate new UPNs for you. Since there is no way of knowing if one of the skipped serial numbers has been used in an official return we cannot simply regenerate numbers from those missing blocks, therefore until the start of the next academic year you will need to obtain UPNs from the LA as they can generate ones that are known to be unused. The problem should be resolved in September, but you might need to double check that the method you are using to generate UPNs is the most efficient and doesn't lead to these skipped serial numbers Edit: Please note, this is not an issue with the 14.1 release as these skipped serial numbers are spread throughout the year.

I have a paranoid approach to mucking about in SQL.. I once very nearly got burnt by a bad script, so I learnt my lesson well!

If you need to change your FileRefs to a new location, the following may help. Please note that this information is given as-is and it is your responsibility to ensure you have a full backup of your data first. I would also recommend testing this on a dummy database first to ensure it doesn't do anything destructive on your live data. First, double check if you have any crazy long FileRefs, if you do, DO NOT PROCEED, bad things could happen: SELECT * FROM DOCCONTENT WHERE RefLine <> 1If you get any results from this statement you'll need some more in depth code to fix things. Assuming you have on-liner FileRefs run the following statement to ensure that the references look like a normal file ref. There are some entries in the DOCCONTENT table that don't really point to a physical file, but we need to ensure that all the others follow a specific format: SELECT * FROM DOCCONTENT WHERE FileRef NOT LIKE '%\Temp\%'If you ONLY see FileRefs here that relate to a .FacRep file, then this is all good and we can proceed again, otherwise again you will need a more in depth script. OK, so we should now be in a position to assume that your references are all playing ball, now test some code to create some new FileRefs that point to your new document storage location: SELECT 'C:\DocumentStorage' + SUBSTRING(FileRef, CHARINDEX('\Temp\', FileRef), 250) NewFileRef, FileRef FROM DOCCONTENT WHERE FileRef LIKE '%\Temp\%'You should see the NewFileRef creates a new file path that looks like where your Temp folder is in the new document storage location and the rest of the file location is correct for your new document storage. Obviously, you'll need to amend the 'C:\DocumentStorage' bit to the relevant folder path. Now, before we write this back to your data, lets make sure we're not creating new crazy long FileRefs that will fail to work: SELECT 'C:\DocumentStorage' + SUBSTRING(FileRef, CHARINDEX('\Temp\', FileRef), 250) NewFileRef, LEN('C:\DocumentStorage' + SUBSTRING(FileRef, CHARINDEX('\Temp\', FileRef), 250)) Length FROM DOCCONTENT WHERE FileRef LIKE '%\Temp\%' ORDER BY LEN('C:\DocumentStorage' + SUBSTRING(FileRef, CHARINDEX('\Temp\', FileRef), 250)) DESCIf you see any Lengths greater than 249 STOP, this won't work with your data. So, finally happy that your document storage can safely move to your new file location, we can go ahead and swap in the new folder structure: UPDATE DOCCONTENT SET FileRef = 'C:\DocumentStorage' + SUBSTRING(FileRef, CHARINDEX('\Temp\', FileRef), 250) WHERE FileRef LIKE '%\Temp\%'Refresh your connections (stop and restart ePortal) and you should now have access to your documents again. Ensure all the configurations for document storage are also pointing to your new location also. As I said at the start, this information is given as-is, you need to ensure that you fully test this before deplying in a live environment. Always, ALWAYS, ensure you have full SQL backups before you run potentially destructive update statement in SQL, and be prepared to have to restore that back in if you find that there are issues when you test the data afterwards.

You need to check the FileRef values in the DOCCONTENT table and make sure that the path you've restore the document storage files to match those. You will also then need to reset the configuration settings for document storage in Admin (and ePortal, if you're still using that) to also point at this new location. That should fix the problem, but as always there may be some individual wobbles with the way your setup works. Note also that if you had previously moved your document storage prior to moving systems (server upgrade, for example) then you might have documents listed against multiple locations in your DOCCONTENT anyway, which you would need to script to correct.

Hmm, perhaps I'm assuming the worst in terms of how intelligent the system is with rebuilding the documents from the paths stored in that table then? In truth, I do think it's somewhat ridiculous that the system even bothers to store the full virtual paths in the table since it should only need the file name and the config settings telling it where the temp storage is to fully recreate the original file from the repository. Perhaps it is able to pick out just the filename section and use that with the settings, but the OP's issue would certainly indicate this may not be the case?

I think you'll find that @michael2k6 is correct on this one. The document storage in Facility stores the full virtual path of the file inside the database, so when you move the location of the document storage around the system can lose track of where it thinks those files should now be. If you take a look in the DOCCONTENT table you might see that the FileRef field is still referencing an old location for the documents from before your migration. If this does not match up with the current location of the document storage folders then this is likely the cause of the issue. I guess there are two possible solutions, neither of which are all that great. You could either relocate the document storage folders back to their original location on the network so that Facility understands where those file references point to. Alternatively, if you need to keep the document storage on your archive server, you would likely need to update the file refs to point to their new location. This in itself could be fairly involved and potentially dangerous as you'd be editing the SQL tables directly. If you need to do this there are some pointers I could give that might help you, but you'd be in an "at your own risk" situation, so please bear that in mind.

Navy: facility_acs_Navy.txt OliveGreen: facility_acs_OliveGreen.txt Orange: facility_acs_Orange.txt Orchid: facility_acs_Orchid.txt Red: facility_acs_Red.txt Yellow: facility_acs_Yellow.txt

If you've upgraded to ePortal 13.3, but aren't really getting on well with the new blue colour scheme, then this post might be of use to you. When Advanced released this version of ePortal, they also bundled in some additional, yet unused, colour scheme image files. I've compiled some css files that make use of each of these colour image sets so that schools can have some control over the colour scheme that ePortal uses. Hopefully, one of these is close enough to your school's branding that you find it useful. As an aside, the colour schemes on offer here are those that are available in Progresso, so anyone planning on migrating might find it useful to pick out a colour scheme from this for when you go live! I've tried to ensure that these files amend the colours on all ePortal screens, but if you do find one that has slipped through with the default blue colour scheme, let me know! Also, please don't judge the css too harshly, I know it's full of kludgy !important rules, but I don't think there is any way around this. I'll attach a preview of the colour scheme so you can decide which one looks best for you, along with a link to a .txt version of the css. You'll need to download this .txt file, rename it to .css and save it to your webapps/eportal/styles/custom folder, then edit the webapps/eportal/styles/ccmimport.css file and change the filename specified to your new css file. You should then be able to refresh your connection to ePortal (you do not need to restart services!) and the new colour scheme should take effect. default: facility_acs_default.txt Amber: facility_acs_Amber.txt DarkBrown: facility_acs_DarkBrown.txt DarkMagenta: facility_acs_DarkMagenta.txt Golden: facility_acs_Golden.txt Green: facility_acs_Green.txt LightBlue: facility_acs_LightBlue.txt Continued in next post...

I used cached Google maps with navigation on a recent holiday abroad, and it worked just fine. I had taken the precaution to turn all data off for the duration, mind you. My main gripe with Google navigation is that you don't get the option to have certain routing selections by default, mainly for the "No Toll" option, which when you live close to the M6 toll road is a must - I sometimes wonder if they aren't in cahoots with the operators given how insistent they are on routing along that damned thing.

A bit complicated, but this basically is a generic solution to pivoting the data from the APPAPPFIELDS table: DECLARE @cols VARCHAR(MAX) DECLARE @sql VARCHAR(MAX) SELECT @cols = COALESCE @cols + ', ', '') + QUOTENAME(ef.Mnemonic) FROM APPAPPFIELDS af INNER JOIN APPEVFIELDS ef ON af.SetId = ef.SetId AND af.RecType = ef.RecType AND af.EventId = ef.EventId AND af.FieldId = ef.FieldId AND ef.LineNum = 1 GROUP BY ef.Mnemonic ORDER BY ef.Mnemonic SET @sql = 'SELECT * FROM (SELECT af.SetId, af.RecType, af.AppCode, af.AppEventId, af.EventId, ef.Mnemonic, af.ValueData FROM APPAPPFIELDS af INNER JOIN APPEVFIELDS ef ON af.SetId = ef.SetId AND af.RecType = ef.RecType AND af.EventId = ef.EventId AND af.FieldId = ef.FieldId AND ef.LineNum = 1) AS SourceTable PIVOT (MAX(ValueData) FOR Mnemonic IN (' + @cols + ')) AS PivotTable' EXEC (@sql) I should note that whilst I've tested this against a sample database I can't guarantee that it won't eat your hamster when you run it against your database, as such you should make sure you have suitable backups etc. before you play with it. As it is only really a slightly complicated select statement, however, I wouldn't anticipate anything really nasty happening, but as it works with an EXEC command it's always possible that some really bizarre stuff in your event specs could cause some SQL injection, which would be a bad thing... Testing on a non-live setup would be advisable.