Devart Forums

Rave report components do not understand LongWord fields and try to cast them to Int64. When you print the report, it bombs due to cast error. I guess Delphi throws an error because it is possible for very large LongWord values to appear to go negative.

Is there some way to restore the old (pre v7.2.7) behavior of using signed int64 fields when MyDAC sees an INT(10) MySQL field?

Hello,

In the latest MyDAC version 7.2.7 we added the new functionality - data mapping, that allows mapping of server data types to IDE types. To fully support data mapping, we made several changes in field creation that also slightly increase performance. In MyDAC 7.2.7 for the MySQL type INT UNSIGNED the TLongWordField field is created. To return the old behaviour, you should add the following mapping rule:After this, for the MySQL type INT UNSIGNED the TLargeintField field will be created. Please note that to use the myIntUnsigned variable, you should add the MyDataTypeMap unit to the USES clause of your unit.

What is the best practice at design time for field types in queries when using the new mapping feature?

My problem:

I use lots of DBGrid (DevExpress QuantumGrids) components that need pre-defined field types for the component's grid field editor. I typically auto-add all the fields to every TMyQuery using your Field Editor feature. Then the QuantumGrid component can auto-create columns for all the TMyQuery fields.

Won't this mapping trick ignore any fields I auto-create? Mapping looks like a run-time tweak, not a design-time one.

Will I need to manually force all the INT(10) fields to LargeInt instead of LongWord in the Field Editor? - the new TMyQuery field editor wants to set everything to LongWord when you auto-add.

Some of these queries are used by both grids and RAVE reports. Everything worked great before the mapping change.

This is a pain - I have hundreds of TMyQuery components to fix in two very large (1.2 millon LOC) apps. There are a two similar size/complexity datamodules in each app:



Best regards,

Kevin G. McCoy

I see there is a new property editor on TMyConnection to handle mapping. Is *this* where I should be doing my mapping instead of a run-time remap?

I am getting typecast errors everywhere in my app when I added the remap call in DataModule.OnCreate

Ok, I figured it out for myself and everything appears to be working.

For the lurkers...

Adding mapping changes in runtime code broke everything. I am not sure how this method would be useful in actual applications.

It turns out you have to make any desired mapping changes in the TMyConnection properties. This does the same thing as the example runtime mapping code, but also makes the mapping changes in the IDE designer. Now both runtime and designtime mapping changes work.

You can then do one of two things to fix the field types.

1. use the TMyQuery fields editor to change all the TLongWordField fields to TLargeIntField either manually or by deleting all the old fields and use Add-all. If you are mapping some other field type, then use the appropriate field types. This method is very slow, tedious and error prone.

2. Use something like GExperts GREP to replace all instances of TLongWordField with TLargeIntField in both DFM and PAS files. This is the quickest. I just fixed several thousand broken fields this way.

Data Type Mapping can be used both in design-time and run-time. If you want to use persistent fields (that are created in design-time), you should set desired mapping rules in design-time before creating them. This way, persistent fields will be created taking into account data type mapping rules. If you don't use persistent fields, you can set desired mapping rules before opening a connection or a dataset in run-time. You can learn more information about Data Type Mapping and its correct usage from the "Data Type Mapping in Data Access Components for Delphi" article in our blog at http://blogs.devart.com/dac/index.php/d ... nents.html