Some NetG content have problem when launched through the LCMS content launcher. It just hanged. By looking at the output produce by the APIAdapter applet console, it was caused by the data truncated for the cmi_value field in the database table. It seem that, NetG SCO try to save the value with a very long characters value. So, to solved this problem, just modify the cmi_value field by extending it's varchar length from 50 to 255 characters.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Shaiful has asked me one question regarding the cmi meta data on student results. He noticed that, each time cmi data are submitted, they overwrite previous results on the server. So, he suggested that, we modify the application to look for previous results and manage this situation within the server application. Well, this approach is “wrong” as it against the rule of the server role in SCORM specification.
What should be done is that the browser it self must retrieve all the previous results, manage them, and resubmit them. When I said “the browser” it's mean is the content itself.
The browser is responsible for doing many things (that are in fact, are much more effectively done by the server – but sadly not in the case of SCORM specification).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some NetG content have problem when launched through the LCMS content launcher. It just hanged. By looking at the output produce by the APIAdapter applet console, it was caused by the data truncated for the cmi_value field in the database table. It seem that, NetG SCO try to save the value with a very long characters value. So, to solved this problem, just modify the cmi_value field by extending it's varchar length from 50 to 255 characters.
Shaiful has asked me one question regarding the cmi meta data on student results. He noticed that, each time cmi data are submitted, they overwrite previous results on the server. So, he suggested that, we modify the application to look for previous results and manage this situation within the server application. Well, this approach is “wrong” as it against the rule of the server role in SCORM specification.
What should be done is that the browser it self must retrieve all the previous results, manage them, and resubmit them. When I said “the browser” it's mean is the content itself.
The browser is responsible for doing many things (that are in fact, are much more effectively done by the server – but sadly not in the case of SCORM specification).