Jasonjac2

Hi All, I have an old system: 2 x EXEs (D7) 330K combined lines of code BDE FibPlus IBX JVCL JCL TMS SMExport (very small amount) Custom Components (very small part) CNWizards – logging – (very small part) I want to end up with on DAC (FireDAC unless anyone talks me out of it) and D10.4 I have invested in "The Delphi Parser". The author is being very helpful, but ultimately for FIBPlus, I am going to get my hands dirty and modify the script to teach it what to convert into what. I was wondering if anyone else has travelled this path or is about to. Things I was interested in. How you did it, what gotchas you got etc. I like the idea of a "brighter than Grep" parser that understands the structure of a Delphi App.

@corneliusdavid potentially collaborate on this? FIBPLus is a bit more complicated than the BDE IMO as there are some advanced properties and also I think the developer had less defaults or whatever it is that ensures the DFM doesn't bloat with a gazilion properties that are just default values. How far are you through?

"necroposting" love it! No I didn't. I didn't get the the tool I was looking at to work had to put the project down. It is back on the agenda, but now moving from 7 -> 12.x! Are you doing the same and how are you getting on? Another entry into the marketplace is GDK who advertise specialising in such migrations. I had a quick chat with them, but haven't progressed it further. I could really do with moving to a later version as there are lots of things I want our app to do that would leverage modern libraries / components that use modern language features.

I have lot of marketing e-mails about the Delphi Parser product https://delphiparser.com/ that mention AI powered. I'm not bashing the product, I just wanted to know what is "AI Powered" about it. I e-mailed, but didn't get a response, so thought I would aske here. Regards, Jason

Oh dear, I didn't mean to start a flame 🙂 Just get to the bottom of it. Actually, has anyone used the product and is it actually any good (AI or No AI)?

I'll check out the about... thanks. Using templates and substitution, even with elaborate conditionals and context info doesn't make it AI to my mind and that is what it used to use to re-write code. "70B model with only Delphi code?" - I could defo google this but would love to hear what you are talking about from you.

Hi, I was looking at the excellent https://github.com/Fr0sT-Brutal/awesome-pascal/ and it reminded me of a discussion I was having a while back about RTC/RealThinClient. I thought one of the examples was remote control / file transfer between 2 PC's, or am I confusing it with another component set? I was looking at https://github.com/teppicom/RealThinClient-SDK/ and couldn't see a suitable example. Anyone remember? TIA Jason

Hi, I had an old D7 + BDE + ODBC -> Sage app that did a simple extract from Sage, did a bit of magic and produced a report. Excellent. We upgraded Sage to V29 and the app wouldn't connect, with a not very useful error message. Excel -> ODBC -> Sage was fine. So I thought I would try with D11 Update 1 + FireDAC. After a few hours of fun (there aren't a lot of ODBC FireDAC examples and I don't have the Sage ODBC driver on my dev box), I got a proof of concept that could connect and I could run an SQL against Sage and get data. To cut a long story short, I built the bare minimum to get the data, save it to XML (Using TClientDataset), load it back up and process the invoice & Invoice_Line tables. The actual bits I want look fine, but then I noticed that some of the data in columns appeared to be the same for the whole column. Many hours later, tracing back through, I go back to my fist example AND "select * from invoice" and then finding invoice 99 Doesn't have the same data as "select * from invoice where invoice_number = 99" FOREIGN_INVOICE_NET="1300" (Actually -5.83 if selected via excel & ODBC or using the specific Where clause) FOREIGN_INVOICE_TAX="260" (Actually -1.17) FOREIGN_INVOICE_GROSS="1560" (Actually -7) INVOICE_NET="1300" (Actually -5.83) INVOICE_TAX="260" (Actually -1.17) INVOICE_GROSS="1560" (Actually -7) I'm a couple of days in now and properly pulling my hair out as they found the problem last week and they need the calculation for the monthly ledger entries to close the month off (read a lot of pressure). Does this ring any bells with anyone, any ideas? My next steps are: - get someone to compile my simple app on the latest D11.3 and see if it has the same issue. - get the data out via Excel and use that as the input to my calcs (a temporary solution and a chunk of work). Thanks for your time and thoughts, Jason Added a short video to demonstrate

https://quality.embarcadero.com/browse/RSP-41225 not my finest bug report as there are too many bits I am not sure of and it related to a Sage install.

@Lars FosdalI will need to take another look at the logs. From my quick look and lack of knowledge about Sage DataTypes, I am not sure I know whether they are correct mappings or not. Back to the best sources of info on FD, short of reading the source and dedicating the next year to it :-). Can you rate Cary Jenson's book and do you know if there are any amendments since it was published 2017? I have tried reaching out to him on linkedIn. I can see I need to start thinking the FD way and so want a good book, series of articles. I will return to this in a few weeks as I am really behind on other work. Cheers, JAC.

Hi @Lars Fosdal so in a simple GUI, single threaded app, when do you call CoInitialize(nil)&  CoUnInitialize? The only boilerplate stuff I have in all my apps is: SetThreadLocale(LOCALE_USER_DEFAULT); GetFormatSettings; Which is somethrowback to problems with Dates under Windows 7. I'll take a look at the monitoring log again to check the data types, but of course, I am not that familiar with the data types expected from Sage. This was a hack app from years ago and my only real interaction with Sage. I see Cary Jenson has a book on FD, but I am not sure it will cover such things. Do you know who the maintainer is?

@Lars Fosdal no I haven't. There are no additional threads - very simple. So I think a member of the ukDevGroup has got to the bottom of it. TDQuery.FetchOptions.CursorKind:=ckForwardOnly This sorts out the incorrect repeating values. There is still something strange going on with other fields. invoice.invoice_type invoice.record_deleted, used to be 0 for false, now is 1792! So I would put the combo as "at risk" and I think I need to come up with best practices for the FD + ODBC + Sage.

No, I haven't. I thought FD was the way to go. I am about 18 hours into trying to sort this now. About to tell the user that I don't have a working solution. So @Lars Fosdal any suggestions now? Any way of seeing what is actually coming back over the ODBC connection, i.e. to remove FD from the issue - clearly Excel and FD don't access the data in the same way as excel has the correct answers.

Post 3 2 rows returned, ITEMS_GROSS wrong for both rows 08/03/2023 15:41 select invoice_number, invoice_type, ITEMS_NET, ITEMS_TAX, ITEMS_GROSS from Invoice where invoice_number = 1 or invoice_number = 2 INVOICE_NUMBER INVOICE_TYPE ITEMS_NET ITEMS_TAX ITEMS_GROSS 1 Product Invoice 1123.04 191.63 214.32 2 Product Invoice 2192.64 374.12 214.32 The actual last line is Invoice 84 84 Product Invoice (from SOP) 182.4 31.92 214.32 182.4+31.92=214.32 - which if the FDQuery is only getting the results back from the ODBC would imply that it is the ODBC connection (Sage that is giving the wrong answer as the FDQuery isn't getting the last row back).

Post 2 - 2 rows incorrect ITEMS_GROSS for row 1, correct for row 2 (the last row returned). 08/03/2023 15:40 select select invoice_number, invoice_type, ITEMS_NET, ITEMS_TAX, ITEMS_GROSS from Invoice where invoice_number <= 2 Copy to clipboard INVOICE_NUMBER INVOICE_TYPE ITEMS_NET ITEMS_TAX ITEMS_GROSS 1 Product Invoice 1123.04 191.63 2566.76 2 Product Invoice 2192.64 374.12 2566.76 4500312661677 15:40:31.418 >> TFDCustomCommand.Fetch [Command="select invoice_number, invoice_type, ITEMS_NET, ITEMS_TAX, ITEMS_GROSS from Invoice where invoice_number <= 2 ", AAll=False, ABlocked=True] 4500312814243 15:40:31.434 >> Fetch [ATable="Invoice", Command="select invoice_number, invoice_type, ITEMS_NET, ITEMS_TAX, ITEMS_GROSS from Invoice where invoice_number <= 2 "] 4500313126584 15:40:31.465 . ENTER SQLFetch HSTMT 0x06D7CD48 4500313283156 15:40:31.481 . EXIT SQLFetch with return code 0 (SQL_SUCCESS) HSTMT 0x06D7CD48 4500313283416 15:40:31.481 >> Fetched [Row=0] 4500313438611 15:40:31.496 . Column [N=1, Type=SLONG, Size=10, Len=4, Data=1] 4500313596585 15:40:31.512 . Column [N=2, Type=CHAR, Size=60, Len=15, Data='Product Invoice'] 4500313751854 15:40:31.528 . Column [N=3, Type=DOUBLE, Size=15, Len=8, Data=1123.04] 4500313907727 15:40:31.543 . Column [N=4, Type=DOUBLE, Size=15, Len=8, Data=191.63] 4500313907801 15:40:31.543 . Column [N=5, Type=DOUBLE, Size=15, Len=8, Data=2566.76] 4500313907856 15:40:31.543 << Fetched [Row=0] 4500313909035 15:40:31.543 . ENTER SQLFetch HSTMT 0x06D7CD48 4500314064373 15:40:31.559 >> Fetched [Row=0] 4500314064134 15:40:31.559 . EXIT SQLFetch with return code 0 (SQL_SUCCESS) HSTMT 0x06D7CD48 4500314220045 15:40:31.574 . Column [N=1, Type=SLONG, Size=10, Len=4, Data=2] 4500314376458 15:40:31.590 . Column [N=2, Type=CHAR, Size=60, Len=15, Data='Product Invoice'] 4500314532680 15:40:31.606 . Column [N=3, Type=DOUBLE, Size=15, Len=8, Data=2192.64] 4500314689069 15:40:31.621 . Column [N=4, Type=DOUBLE, Size=15, Len=8, Data=374.12] 4500314845359 15:40:31.637 . Column [N=5, Type=DOUBLE, Size=15, Len=8, Data=2566.76] 4500315001246 15:40:31.653 << Fetched [Row=0] 4500315157831 15:40:31.668 . ENTER SQLFetch HSTMT 0x06D7CD48

@Lars Fosdal starting to loose the will :-(. But I have enabled FD logs and also enabled ODBC logs. I don't think ODBC logs gives me data being returned, so I can't have a smoking gun for Sage being the culpret. I will post each of the tests below as separate posts for clarity I think. I have pulled out bits from the logs, I am happy to supply you with the logs if they make any more sense from you. There will be a conclusion at the end. Post1 - single row SageExportTest20230303_11_1_32Bit 08_1507.wasexe 20230308_1537 Demo 11U1 32 Bit.txt 08/03/2023 15:38 List ODBC 08/03/2023 15:38 Connect 08/03/2023 15:38 Select select invoice_number, invoice_type, ITEMS_NET, ITEMS_TAX, ITEMS_GROSS from Invoice where invoice_number = 1 Copy to Clipboard INVOICE_NUMBER INVOICE_TYPE ITEMS_NET ITEMS_TAX ITEMS_GROSS 1 Product Invoice 1123.04 191.63 1314.67 Correct ITEMS_GROSS 499603908269 15:39:20.543 >> Fetched [Row=0] 4499604064212 15:39:20.559 . Column [N=1, Type=SLONG, Size=10, Len=4, Data=1] 4499604221005 15:39:20.574 . Column [N=2, Type=CHAR, Size=60, Len=15, Data='Product Invoice'] 4499604377054 15:39:20.590 . Column [N=3, Type=DOUBLE, Size=15, Len=8, Data=1123.04] 4499604533425 15:39:20.606 . Column [N=4, Type=DOUBLE, Size=15, Len=8, Data=191.63] 4499604688718 15:39:20.621 . Column [N=5, Type=DOUBLE, Size=15, Len=8, Data=1314.67] 4499604688873 15:39:20.621 << Fetched [Row=0] 4499604845731 15:39:20.637 . ENTER SQLFetch HSTMT 0x06D7CD48 From Logs: 4499602502605 - > 4499605626273

Unidirectional = same. As @Lajos Juhász says, you can't hook up grid OR in fact issue a fdQuery.savetofile it would appear. I had to cobble together a copy to clipboard for my test. I can confirm that D11Upd1 32 bit on Sage V28 using unidirectional still exhibits the same behaviour. And on the example where I select 2 x rows using an OR, the actual value in the column that is wrong is actually the value in the very last entry in the whole table. i.e. it shouldn't even be part of the resultset. I will try once with the logging turned on and see what it gives me. Will it give me all the data being pulled back from down the pipe? Are there any good / great articles / white papers / books on FD that are better than Google + docwiki?

Looks like you can't "savetofile" for a unidirectional query. As I can't hook up to a grid, I was hoping to just saveToFile <filename>, JSON to keep it simple.

Repeatable in Save V28 demo data, About to test with Unidirectional as suggested by @Lars Fosdal. Any other tests Lars?

10.4.2 32 bit exhibits the same on the Demo Data for Sage v29. Next to check Lars, setting unidirectional. Also, any others to try? In my tiny example, I let the fields be created dynamically due to user provided SQL. Do you think anything about mappings etc could be the cause? Thanks for the article. I think right now, it is probably a bit deep for me, but I will read as I am going to have to become a FD expert at some pioint. I am about to have to break off and work out how to get the data a different way and process it, e.g. -> excel and process it using Delphi to get the user what they want. I need to make it reproducible on different DB's with difference V of Delphi, raise a QP (my colleague says 0 point raising with Sage as they will say "it works with Excel and we don't support Delphi"). I have a colleague who is going to test on V28 & V29 using my code - recompiled in D11.2

64 bit exhibits the same issue. Do you think that encoding / language / locale issues are likely. Just to reiterate the problem in its simplest form: select one invoice by invoice number and the numbers look right. Select multiple invoices (2) and some of the fields get incorrect values (same column same value) and it is repeatable.

That is my next check - we don't use any 64 bit apps onsite, so hadn't even thoughts about it, so just built a 64 bit version and going to create a 64 bit DSN now. Thanks for the thought. In terms of reporting to EMBT - which is bottom of my priority list prior to getting the data I need, I think it will be tricky as the current use case is Sage specific as I only have a sage example.

A long shot and completely related to my other post about d11-update-1-firedac-odbc-to-sage-returning-wrong-data. If I could make the original connection open then all would be good. Basically when I try and connect to the DB in my old app, I get a generic error. I have turned on ODBC logging, which didn't help. Knowing someone else has it working would mean it was worth trying to get to the bottom of that problem, rather than trying to track down a potential bug in D11. TIA JAC.

Thank for the additional info, as you say, it won't be applicable here as I am doing the select from the ODBC source to Sage, not via Excel and it isn't a format issue.

@brian Thank - I didn't realise they were hooked up. They really shouldn't make any difference until the TClientDataset has opened, but I totally get your point and will do another test.