Search the Community

Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 When creating or modifying entries on the reference lists, there doesn’t appear to be any check on whether a duplicate is being created. DLN:CC appears to (universally as far as I can see) allow the user to create duplicate entries. In the case of, say, Operator Roles, one can create two roles both called Supervisor. When one comes to associate Operators with an Image Set, you have to pick a role for the association, and you will see two indistinguishable Supervisor roles to choose from, and even if the tooltip / description had been populated, it isn’t visible. In some cases there may legitimately be multiple items such as tripod or light stand, but that would be covered by having Quantity > 1 in the equipment record as there would be no need to differentiate between them. I can envisage relatively few cases where near-duplicate entries might be required – but they would still need visually distinct names to allow them to be correctly associated. For example, if a user had two camera bodies of identical model, but different serial numbers – and the user wished to keep track of which body was used on a shoot because of the age of the body, or perhaps different firmware. Two equipment records could be created – but unless there was something distinctive about the names, the user would not know which body to associate with the image capture. It should be relatively easy for the alert user to monitor this on small lists (especially once they are sorted alphabetically) but once lists get longer, or perhaps a DLN:CC instance has multiple users, the risk of inadvertent creation of duplicate entries will increase. I would strongly suggest that DLN:CC shouldn’t allow creation of any records with identical names. List ‘shuffles’ – a disconcerting phenomenon – only seen, I think, on the Equipment Overview list. If you open the Equipment Overview and then highlight a row and click [Details], or double-click a row and then [Close] the details screen, the underlying list remains exactly unchanged. However, if you open the details and then change something (not necessarily the Name) and then click [Save], when you then [Close] the details screen, the entry you clicked on has, at first sight, disappeared! On further inspection though, it has either moved to display row 9 or the bottom of the list. This is somewhat disconcerting! If the operator has manually sorted the equipment list before activating & changing details, then the list seems to survive un-molested in the chosen order (unless the list was alphabetical and the name has changed in which case the resultant change to maintain alphabetical order is performed correctly).

Re Beta 1.0.3 (DB version 2.2.3) Build Apr 26 2018 15:55:31 This is initially relates to silent corruption of a field in the Equipment Overview, but may have wider implications… If one is using DLN:CC Equipment Overview as a mini asset register as per the sample database, and populates a price, there are silent and insidious problems if one enters anything other than digits 0 to 9 or a decimal point by including say a currency symbol (e.g. £ for GBP) or a comma (used by many to delimit thousands, or in some regions as the separator twixt the integer portion and decimal fraction of a real number). What happens is: On the equipment overview details screen, the data entry field (whether adding a new record or editing an existing record) allows one to enter costs such as 123.45 1234.56 1,234.56 1.234,56 £123.45 £1,234.56 GBP 123.45 without any objection either when the Price field is exited or when the [Save] button is clicked. However, if one then saves, closes and goes back to view the record details, in all except the first two cases, the Price is now ‘0’. Without seeing the code, from the above it appears the failure is because the UI is accepting (meaningful and valid) ‘text’ but the database is only accepting a real with a decimal point separator. Insidiously, the whole database INSERT / UPDATE isn’t failing – if for example the serial number and price are changed, the serial number is saved/updated but the price can be corrupted to 0 if it contains anything except 0 to 9 or a decimal point. Couple of points: As there is unlikely to be any arithmetic on equipment prices, in this specific case might be best to just make the Price column in the database a text varchar, rather than numeric, column. More importantly though: 2. If there are restrictions as to what can be stored in a field, the UI needs up-front validation either when the field is exited or when the [Save] button is clicked. 3. IF the UI is posting the input from the user intact and it is being rejected by the database, then it raises the possibility that the result of commands which modify the database may not be being monitored. Dave