Very Crazy Error in Postgresql X Fastreport Registry

Asked

Viewed 190 times

1

I have several tables that do Masterdetail among themselves, I will not put the structure here because it is very complex, are 26 tables involved.

The error is as follows: in a table there is a record that when opened by Fastreport it simply gives me a "Access Violation" without foot or head that I can’t see what the problem is, I already opened the table compared to records that work and nothing, nothing to find the problem.

If I ignore that one record it works.

I edited the contents of the table where there is text by putting a simple "x" and it worked, the impression I have that is must have some character in the middle that is not accepted by the combination Postgresql x Fastreport.

The user uses a lot of copy and paste on the system and it is necessary as many documents are in Word to be transported to my system, but I cannot 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++ already displayed all characters to see if you thought, but no chance.

In the Delphi application I open the record without error, but when I have the report made in Fastreport it gives the error.

The problem is in Postgresql and Fastreport compatibility, but I am already without parameter to solve the problem.

  • Try to set the charset to be used on the connection before any interaction with the Database SET NAMES='UTF-8' or SET NAMES='LATIN1'

  • I already do that, the problem is that only in Fastreport he yells

  • Then maybe the problem is in Fastreport and not in Postgresql?

  • I have already had this problem using Fastreport. The problem is time to "print" "harmful" characters. A simple way would be to use a Normalize() function that removes or replaces harmful characters with others.

  • 1

    {Substitui caracteres especiais por equivalentes ASCII}
Function ReplaceNonAscii(const s: String) : String;
var i, pos: Integer;
const undesiredchars: String= '/ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÜÚÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùüúþÿ';
const replaces: String= ' AAAAAAACEEEEIIIIDNOOOOOxOUUUbBaaaaaaaceeeeiiiionooooo ouuuby';
Begin 
 SetLength(Result, Length(s));
 for i:=1 to Length(s) do
 if (s[i] in [#32, #48..#57, #65..#90, #97..#122]) then
 Result[i]:= s[i]
 else
 begin
 pos:= AnsiPos(s[i], undesiredchars);
 Result[i] := replaces[pos+1];
 end;
end;

  • @Marcos Regis this function will replace accented characters, cedilhas and the purpose is not? If it is can not use, because it is a document and has to go with the correct formatting of our wonderful Portuguese language, what I was wondering is if there’s a way I can select the database that shows me which characters are not supported by latin1, I’m searching how to mount this select

  • Actually, you’ve tried using utf8decode and utf8encode?

Show 2 more comments

1 answer

0


I managed to solve the problem, as it involves many tables and joins Inner was not easy, but I found the problem, it turns out that another programmer created a postgre Procedure that returned Varying Character of undefined size and Delphi recognizes as a string that has the limit of 255 characters and this result can exceed that mark, how to visualize using a Tmemo in Delphi it does not scream, but the Fastreport Tfrxmemo was not able to understand this as a string of size 255 with more characters.

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

Step-by-step solution:

1 - Modify the postgresql function to return type TEXT and not Character Varying, so Delphi recognizes as Tmemofield that is correct 2 - Rebuild the Delphi components to get the new type 3 - Rebuild Fastreport components to get the new type

Now everything ok

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

Browser other questions tagged

You are not signed in. Login or sign up in order to post.