Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 10 total |
Problem with a DECIMAL(19,2) field |
Tue, Nov 30 2021 9:28 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | I've just returned to a project after a length absence (which will include one or two versions of ElevateDB) and I have a problem. I have a field in a table defined as DECIMAL(19,2). It shows up as a defined field in D2007 as TBCDField. Prior to leaving off the project I had things working pretty well. The form in which I updated the table in question worked (I'm returning to do some documentation - shudder). Now it doesn't . The statement things break down on is
dm.Ledger_Value.AsCurrency := ietValue.AsFloat; and the error is one I've never seen before and don't really understand. Debugger Fault Notification --------------------------- Project E:\MOA - DEV\MOA.exe faulted with message: 'datatype misalignment at 0x76f98658'. Process Stopped. Use Step or Run to continue. --------------------------- OK --------------------------- I've disabled triggers on the table in case they were what was causing the problem but no success. Tried installing a 2019 version of ElevateDB - no success HELP Roy Lambert |
Tue, Nov 30 2021 10:54 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | I've now tried repairing the table - no joy, deleting & re-creating again no joy
Roy Lambert |
Wed, Dec 1 2021 5:52 AM | Permanent Link |
gripsware gripsware datentechnik gmbh | Roy Lambert wrote:
I've now tried repairing the table - no joy, deleting & re-creating again no joy Hi Roy, if I remember right, we had some problems with Decimal fields too. I could check... dm.Ledger_Value.AsBCD := ietValue.AsFloat; or dm.Ledger_Value.Value := ietValue.Value; |
Wed, Dec 1 2021 6:35 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | gripsware
Thanks for the suggestion but still not working. The puzzling thing is that this did work, even if I hadn't tried all functions in the program I couldn't miss this one because its the basic transaction insert / edit form. Roy Lambert |
Wed, Dec 1 2021 8:44 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | I have a 2 drive bay laptop and keep my W7 OS on a 120GB SSD - this gets cloned occasionally, the last time was 12/5/2021. I just briefly swapped the clone into my laptop and the problem goes away. My quest now is what amongst the bits and pieces I've installed has caused the problem. I have only 17 items in programs & features installed after 12/5/2021 but I'm not sure where else I might need to look.
If anyone has any thoughts I'd appreciate them. Then again I might just revert back to the old clone Roy Lambert |
Thu, Dec 2 2021 11:14 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Finally, after c8 hours, I finally traced down the culprit (I think). I wrote code to load a custom font (shown below my sig), taking that out and the problem has gone.
Next to figure out why Roy Lambert unit NLHCharLoader; interface uses Classes, Windows; {$R nlhdings.res} const nlhCharClock = 33; // Time lookup nlhCharTick = 34; // A tick nlhCharDropDown = 35; // General dropdown / lookup nlhCharTwoForms = 36; // Image lookup nlhCharBlackCircle = 37; // Colour lookup nlhCharOpenBook = 38; //Date & time lookup (its a diary) nlhCharLightening = 39; // QuickLookup nlhCharSquare = 40; // Unknown Date/Time type nlhCharCalendar = 41; //Date lookup nlhCharCalculator = 42; // calculator nlhCharKeyboard = 43; // On screen calculator (the calculator symbol is naff) nlhCharPhone = 44; // Dial phone number nlhDingFont = 'NLHDings'; implementation function LoadResourceFont(const ResourceName: string): boolean; var ResStream: TResourceStream; FontsCount: integer; HFont: THandle; begin ResStream := tResourceStream.Create(hInstance, ResourceName, RT_RCDATA); HFont := AddFontMemResourceEx(ResStream.Memory, ResStream.Size, nil, @FontsCount); Result := (HFont <> 0); ResStream.Free(); end; initialization LoadResourceFont('NLHDings'); { Note: This will run only once since the various instances of the unit are shared I'm not bothered about removing from memory since I'll want these characters available for the life of the program - they are part of the GUI } end. |
Fri, Dec 3 2021 7:53 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Roy,
<< Finally, after c8 hours, I finally traced down the culprit (I think). I wrote code to load a custom font (shown below my sig), taking that out and the problem has gone. >> That could just be a coincidence. The font loading may just change the memory enough that it changes the symptoms of the problem or makes it go away. My suggestion would be to run the application with FastMM4 and FullDebugMode turned on. That will usually catch any memory overwrites/misbehaviors pretty close to when they happen. Or, at the very least, they will give you some idea of where an issue may occur. Roy Lambert unit NLHCharLoader; interface uses Classes, Windows; {$R nlhdings.res} const nlhCharClock = 33; // Time lookup nlhCharTick = 34; // A tick nlhCharDropDown = 35; // General dropdown / lookup nlhCharTwoForms = 36; // Image lookup nlhCharBlackCircle = 37; // Colour lookup nlhCharOpenBook = 38; //Date & time lookup (its a diary) nlhCharLightening = 39; // QuickLookup nlhCharSquare = 40; // Unknown Date/Time type nlhCharCalendar = 41; //Date lookup nlhCharCalculator = 42; // calculator nlhCharKeyboard = 43; // On screen calculator (the calculator symbol is naff) nlhCharPhone = 44; // Dial phone number nlhDingFont = 'NLHDings'; implementation function LoadResourceFont(const ResourceName: string): boolean; var ResStream: TResourceStream; FontsCount: integer; HFont: THandle; begin ResStream := tResourceStream.Create(hInstance, ResourceName, RT_RCDATA); HFont := AddFontMemResourceEx(ResStream.Memory, ResStream.Size, nil, @FontsCount); Result := (HFont <> 0); ResStream.Free(); end; initialization LoadResourceFont('NLHDings'); { Note: This will run only once since the various instances of the unit are shared I'm not bothered about removing from memory since I'll want these characters available for the life of the program - they are part of the GUI } end. Tim Young Elevate Software www.elevatesoft.com |
Fri, Dec 3 2021 8:20 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Got that wrong - after much messing about its not the culprit - the search continues
Roy Lambert |
Fri, Dec 3 2021 8:30 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Tim
<<That could just be a coincidence. The font loading may just change the memory enough that it changes the symptoms of the problem or makes it go away.>> Yup I think you're right <<My suggestion would be to run the application with FastMM4 and FullDebugMode turned on. That will usually catch any memory overwrites/misbehaviors pretty close to when they happen. Or, at the very least, they will give you some idea of where an issue may occur.>> I run with FastMM normally but I don't have FullDebugMode on yet - will soon though. I do have another candidate for the cause as well. Roy Lambert |
Fri, Dec 3 2021 9:02 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Finally tracked it down to an alteration in a subclassed table component of mine - at least I hope so
Roy Lambert |
This web page was last updated on Tuesday, May 14, 2024 at 07:14 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |