Very crazy error in registry PostgreSQL X FastReport

0

I have several tables that make MasterDetail with each other, I will not put the structure here because it is very complex, there are 26 tables involved.

The error is as follows: a table has a record that when opened by FastReport it simply gives me an "Access violation" without foot or head that I can not see what the problem, I already opened the table compared to records that work and nothing, nothing to find the problem.

If I ignore that single record it works.

I edited the table contents where there is text by placing a simple "x" and it worked, the impression I have is that there should be some character in the middle that is not supported by the PostgreSQL x FastReport combination.

The user uses a lot of copy and paste in the system and is necessary because many documents are in Word to be transported to my system, but I can not identify which character comes from the word that causes this problem.

The error is below:

    [Window Title]
Sistema

[Content]
EAccessViolation error raised, with message : Access violation at address 0040C0B1 in module 'perfil.exe'. Read of address F3746176

[OK]

In notepad ++ I already displayed all the characters to see if I was, but no chance.

In the Delphi application I open the registry without error, but when I send the report to FastReport it gives the error.

The problem is in the PostgreSQL and FastReport compatibility, but I'm already without parameter to solve the problem.

    
asked by anonymous 22.01.2018 / 14:01

1 answer

0

I managed to solve the problem, as it involves many tables and inner joins was not easy, but I found the problem, it happens that another programmer created a procedure in postgres that returned character varying of undefined size and delphi recognizes as string that has the limit of 255 characters and this result can exceed this mark, as for visualization I use a TMemo in delphi it does not scream, but FastReport's TfrxMemo was not able to understand this as a 255 character string with more characters.

Now it makes sense to accessviolation because the text was trying to occupy a memory space limited to 255 characters

Step-by-step solution:

1 - Modify the postgresql function so that it returns type TEXT and not Character Varying, so delphi recognizes it as TMemoField which is the correct one 2 - Rebuild delphi components to get the new type 3 - Rebuild the FastReport components to catch the new type

Now everything is ok

Thanks for the help of the colleagues, sometimes they do not give the right answer, but with their answers it makes us discarding options that maybe we would not have thought.

    
30.01.2018 / 18:21