Neat how you did that you must show me how. I like it very much.
I've used FastStone Capture (faststone.org, meh can't link yet

) which is awesome for screenshots and screen recording in this situation. It's a Shareware, but the licence is pretty worth it if you make lots of documentation which include screenshots. For example it's capable of making a screenshot of a full height window with scrollbars in 1 operation (you select the window and it does the rest). The GIF is made from Photoshop, in the import menu there's an entry to import animations frames from a video. I had to convert the video in a MPEG-4 format, as FastStone produces only WMV files, but there are a lot of tools to do this simple task, even online converters (if the video isn't too large). Then when frames are imported in Photoshop you can "Save for Web" and optimize the size of your GIF... I could have posted the video somewhere too, but GIF is faster and you can usually see them anywhere
About my issue, well I also think Galaxiom must be close when he says the precision what causes the scientific notation to appear, but I also noticed something. The 15 digits without scientific notation can be reached if you use "Fixed" as format, the only explanation I see at the moment as to why the limit changes with the format is that: 123456789012 (12 digits) is represented as 123,456,789,012 (15
characters) in "Standard" format, if you use "Fixed" you can have numbers like 123456789012345 (15 characters too!) before the scientific notation kicks in when you edit the value... so it might just be that Access considers that passed the 15 characters length (including thousand separators, for whatever reason) it will display the number in scientific notation when you try to edit it.
I don't see many reasons why Access behaves like this, maybe because most of the time when you deal with numbers as large as that you want a shorter way to type them.
At some point I considered switching to a different scale, dividing all these values by 1000, but unfortunately some of the fields holding such data have really small values like 800 and the same field in other records will have values in range of billions... so it's not really possible to do this division and still represent all the data accurately without risking rounding errors somewhere along the line.