As this is reproducible one server and not another – and with same data – it must have something to do with a specific server environment/configuration. To find out what it exactly is causing tis without access to the server, would for us be like searching a needle in a haystack with our eyes blindfolded.
Was it possble that we could have temporary read access to the data on this server (on another ‘faked’ dataset where it is reproducible)? If so please send credentials and details to [email protected]. If your client will not allow us to access the real data, then please try
1) duplicate the problematic table (dump this table, and import to another database, or just to a new differently named table, for instance)
2) verify if problem persists with the new duplicated table s well.
3) (if required) delete most ofte data in this table (say except for 50 or 100 rows), ‘fake’ sensitive data in remaining rows, again verify that problem persists.
4) provide us access to the duplicated table.
