Invalid SQL: INSERT INTO `swsessions` (`sessionid`, `ipaddress`, `lastactivity`, `useragent`, `isloggedin`, `sessiontype`, `typeid`, `dateline`, `status`) VALUES('5b8577b0834c99c89f9adf1f0523b887', '54.81.157.56', '1503094807', 'CCBot/2.0 (http://commoncrawl.org/faq/)', '0', '40', '0', '1503094807', '0'); (The table 'swsessions' is full)
Warning: Cannot modify header information - headers already sent by (output started at C:\Inetpub\support.inm.com\includes\functions.php:410) in C:\Inetpub\support.inm.com\includes\functions.php on line 1612
Understanding sort order behavior when updating data - Support Center
inm logo
Corporate Website | Contact | Store | Support | Login  
     


Knowledgebase
View categorized listing of all common frequently asked questions.
Downloads
View our categorized library of downloads for all necessary manuals, software, etc.
 Article Options
Support Center » Knowledgebase » INM V12 Database for Director » Understanding sort order behavior when updating data
Support Page Banner
 Understanding sort order behavior when updating data
Product:Platform:Area:Version:
INM V12 Database for Director Windows, Macintosh General database and table use Versions 1.x-3.x

Summary

Updating a field that is used in the current index can yield a potentially unwanted - although consistent - behavior.

Example

Imagine a database that has the following structure:
[TABLE]
MyFavoriteThings
FIELDS]
Preference integer indexed
Thing string
[END]

which contains the following records:

(Preference, Thing)
27, Raindrop on roses
35, Whiskers on kittens
50, Bright copper kettles
54, Warm woolen mittens
60, Round paper packages tied up with strings
75, Cream-colored ponies
87, Crisp apple strudels
92, Door bells and sleigh bells
95, Schnitzels with noodles
100, Wild geese that fly with the moon on their wings

The table is currently sorted by order of "Preference", using that field's index and the current record is the first record (27-Raindrop on roses).

Any modification to the "Thing" field does not affect the order of the selection. However, modifying the "Preference" field would automatically cause the table to be resorted with respect to the current index's sort order.

For example, modifying the value 27 above for 90 would instantly update the selection to the following order, with the current record pointing to the 7th record.

(Preference, Thing)
35, Whiskers on kittens
50, Bright copper kettles
54, Warm woolen mittens
60, Round paper packages tied up with strings
75, Cream-colored ponies
80, Crisp apple strudels
90, Raindrop on roses
92, Door bells and sleigh bells
95, Schnitzels with noodles
100, Wild geese that fly with the moon on their wings

This "repositioning" occurs right after calling mUpdateRecord.

This behavior may seem even stranger when the INM V12 Database Behaviors are used. In that case, if the current record is #1, the value 27 is changed to 90 and the user clicks on the Next button (theoretically to view record #2: 35-Whiskers on kittens), the record 50-Bright copper kettles is displayed. This is because the mGoNext method called by the Next button updates record #1 thus relocating it as record #7, and then goes to the new record #2 which is 50-Bright copper kettles.

To avoid this behavior, you must prohibit the modification of fields used in the current index. Or better yet, create an additional indexed field that can be used as an internal ID. This is how many database engines work internally.



Article Details
Article ID: 114
Created On: 26 Sep 2006 02:43 PM

 This answer was helpful  This answer was not helpful

inm general footer
Services Xtras Go Products Support Gallery Store Download About Us Contact Newsroom