mvanrijnen

hmz, have to take a look at that if we upgrade to D12

I think they should also change the BDSCatalogRepository BDSCatalogRepositoryAllUsers paths, by default they do not have a version in it (at least untill 11.3), i always change these to something like "D:\Data\Delphi\Catalog\22" (and then the same value for BDSCatalogRepository as for BDSCatalogRepositoryAllUsers)

but is i read it correctly how to solve this, it's just plain old DLL hell, not so difficult to solve ....

Maybe the problem is that the Beta testing is done on "clean" systems only ?

Very strange, if you get a response code of 200 and you see the body in the proxy it should have a value, can you see if request.Response.Content contains any text? (debug it right after request.execute in your code)

so you do get a response now, try now without the Async, i think problem might be in the Async method now. (not in the method, but how you handle it). I never used that method, i believe you have to have an event catching the response or something like that ? (can check that tomorrow, i now go to bed : )

When will the CE release will be released? (i have the CE version on my private laptop)

Don ;t think thats possible with the Params property, it all ends up merging the diffentt params from client/request etc, and there they get overwritten when having the same name. You have to fill your request body by hand then i think.

Best way is to use a proxy, for a list see for example: mitmproxy Alternatives: Top 10 HTTP(S) & Web Debuggers | AlternativeTo ( i use mitm and/or fiddler, charles is also mentioned by @Uwe Raabe i believe) let mee see if i can capture some output for this. Here it works like a charm..... var ...... prm : TRESTRequestParameter; begin ..... req := TRESTRequest.Create(nil); try req.Client := FRestClient; req.Method := TRESTRequestMethod.rmPost; req.Resource := cExtensionResource; ..... prm := req.Params.AddItem(); prm.Name := 'testmultivalue'; prm.AddValue('Value_1'); prm.AddValue('Value_2'); prm.AddValue('Value_3'); prm.AddValue('Value_A'); req.Execute(); ..... don't mind the 400 error, i just changed a get into a post to try.

Which Delphi version? In 11.3 there are a couple of overloads, but not that "overload version"? found it 🙂 overread the parameterless in your post that in combination with the .AddValue would be the solution

It searches for the param with the name, and changes the value (and other properties of the parameter) I don't think this is possible with the default parameters in the TRestRequest. You have to fetch the TRestRequest parameter and use the .AddValue method i think.

Thats very strange, You have assigned the correct TRestclient to the Request? I use 2 seperate (3 actually), TRestclients: * 1 for the requests * 1 for the Authorization * 1 for uploads (large files) So i can keep them seperate because they differ a little bit somesitimes (BaseURL especially) Preperation: function THSMSGraphAPI.NewRestClient(const ABaseURI: string): TRESTClient; begin Result := TRESTClient.Create(ABaseURI); Result.SecureProtocols := [THTTPSecureProtocol.TLS12, THTTPSecureProtocol.TLS13]; if not UserAgent.IsEmpty then Result.UserAgent := UserAgent; Result.ProxyServer := ProxyServer; Result.ProxyPort := ProxyPort; end; procedure THSMSGraphAPI.CheckClients; begin if not Assigned(FRestClient) then FRestClient := NewRestClient(CNST_MSGRAPH_BASEURL); if not Assigned(FAuthClient) then FAuthClient := NewRestClient(CNST_MICROSOFT_AccessTokenEndpoint.Replace(CNST_TENANTNAME, TenantName, [rfReplaceAll, rfIgnoreCase])); if not Assigned(FUplClient) then FUplClient := NewRestClient(''); end; procedure THSMSGraphAPI.CheckCreds; begin CheckClients(); if not DoCheckAuthorisation() then raise Exception.Create('Authorization fail.'); FRestClient.AddAuthParameter('Authorization','Bearer ' + AccessToken, pkHTTPHEADER, [TRESTRequestParameterOption.poDoNotEncode]); end; [code] warning, i only use client_credentials as grant_type a simple routine [code] function THSMSGraphAPI.FindCalendar(const ACalendarName: string; var ACalendarID: string; const ASkipCreds :Boolean): Boolean; var cal : TMSGraphCalendarListItem; cals : TMSGraphCalendarListItems; req : TRESTRequest; begin Result := False; ACalendarID := ''; if not ASkipCreds then CheckCreds(); req := TRESTRequest.Create(nil); try req.Client := FRestClient; req.Method := TRESTRequestMethod.rmGET; req.Resource := CNST_RESOURCE_LISTCALENDARS.Replace(CNST_SENDASEMAILADDRESS, AccountEmailAddress, [rfReplaceAll, rfIgnoreCase]); req.Execute(); if not LogInvalidResponse(req.Response, True, 'THSMSGraphAPI.FindCalendar') then begin TgoBsonSerializer.Deserialize(req.Response.Content, cals); for cal in cals.Value do if (cal.name=ACalendarName) then begin ACalendarID := cal.id; break; end; end; finally Result := not ACalendarID.IsEmpty; req.Free; end; end; (ps this code was just a quick way to get the calendar i needed, have to expand to the search/filter possibilities from MSGRaph API) i always create the clients&requests by hand in my final code.

very strange, try this 🙂 FRestClient.AddAuthParameter('Authorization','Bearer ' + AccessToken, pkHTTPHEADER, [TRESTRequestParameterOption.poDoNotEncode]); so, add the param to the client instead of the request, and use AddAuthParameter for this. (maybe try with settings this in the request also). tried all kind of variants, even pasted your code line, here it always works., you tried it with Execute instead of ExecuteAsync i think you should try a bit harder to get a proxy running for debugging this kind of stuf, works the best to find out differences. the different variants i tried, the last one is copied from your code posted here: // req.Resource := cExtensionResource; // FRestClient.AddAuthParameter('Authorization','Bearer ' + AccessToken, pkHTTPHEADER, [TRESTRequestParameterOption.poDoNotEncode]); // req.AddParameter('Authorization','Bearer ' + AccessToken, pkHTTPHEADER, [TRESTRequestParameterOption.poDoNotEncode]); // req.Params.AddItem('Authorization','Bearer ' + AccessToken, pkHTTPHEADER, [TRESTRequestParameterOption.poDoNotEncode]); req.Params.AddItem('Authorization', 'Bearer ' + AccessToken, TRESTRequestParameterKind.pkHTTPHEADER, [poDoNotEncode]); req.Resource := cExtensionResource; req.Execute();

type change this: RESTProfileRequest.Method := TRESTRequestMethod.rmGet; RESTProfileRequest.Resource := 'v1.0/me'; RESTProfileRequest.Params.Clear; to RESTProfileRequest.Method := TRESTRequestMethod.rmGet; RESTProfileRequest.Params.Clear; RESTProfileRequest.Resource := 'v1.0/me'; i think somethings get cleared with the params clear. second also instead of .Params. use .AddParameter with the Access token you mean the value in: FConnection.AuthToken ?

And make sure to use F9 (not ctrl-shift-F9), or hit the run icon with the bug.

They are all using the same TRestClient ? ( i always set these things manually) restClient.ProxyServer := Self.ProxyHost; restClient.ProxyPort := Self.ProxyPort; Could also be the case that you do not use the 127.0.0.1 address, but your non-localhost address (eg 192.168.1.44).

Yes, but the question is where the data changes? As i demonstrated that Delphi & .Net creates the same b64 data.

THe ThisWhatDelphiRestGet.txt file, is that the immediate output of your Delphi method? Because i thought (ot ouf my headnot checked) that the TNetEncoding.Base64.EncodeBytesToString method returns CR/LF's in its result? see here: program TestBase64Encoding; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.IOUtils, System.NetEncoding; const cSourceURL = 'https://file-examples.com/storage/fe1134defc6538ed39b8efa/2017/10/file-sample_150kB.pdf'; cInputFilename = 'C:\SWDev\_TestData\file-sample_150kB.pdf'; cOutputFilename = 'C:\SWDev\_TestData\file-sample_150kB.b64.delphi.txt'; cOutputFilename2 = 'C:\SWDev\_TestData\file-sample_150kB.b64.delphi-CRLF.txt'; begin try TFile.WriteAllText(cOutputFilename, TNetEncoding.Base64.EncodeBytesToString(TFile.ReadAllBytes(cInputFilename))); TFile.WriteAllText(cOutputFilename2, TNetEncoding.Base64.EncodeBytesToString(TFile.ReadAllBytes(cInputFilename)).Replace(#13#10, '', [rfReplaceAll])); except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end. .Net using System.IO; using System.Text; using System.Runtime.CompilerServices; namespace ConsoleApp { internal class Program { private const string cSourceURL = @"https://file-examples.com/storage/fe1134defc6538ed39b8efa/2017/10/file-sample_150kB.pdf"; private const string cInputFilename = @"C:\SWDev\_TestData\file-sample_150kB.pdf"; private const string cOutputFilename = @"C:\SWDev\_TestData\file-sample_150kB.b64.dotnet.txt"; static void Main(string[] args) { File.WriteAllText(cOutputFilename, Convert.ToBase64String(File.ReadAllBytes(cInputFilename))); } } } You can see that the CRLF stripped version is the same as the .Net version of the outputfile. Somethings mixes up the data for TS, Result: file-sample_150kB.b64.delphi.txt ile-sample_150kB.b64.delphi-CRLF.txt file-sample_150kB.b64.dotnet.txt

Are the totally different, or: - Is it just the padding that differs - Is the .Net B64 a long string, and the Delphi B64 is multilne (a string with CR/LF's in it?) Can you dump here the 2 different strings?, use a testfile!

ah, thats new for me 🙂 , in that case, dump the manual downloaded sqlite DLL 🙂 and just use FireDac

also for community edition?

It's one of the (many) main reasons, at the moment, (aside Costs/Investments & Time) not to move to other Development environment, yes. There's a lot of code in triggers etc, which is a factor not to move to other database, at this moment. Of course is moving to an whole other platform bringing a lot of costs and time, 20years of development in the main application here, it's not that we have that written to .Net (for example) in 6 months, probably will take years. okay Only thing was a bit overdone 😉

Probably some needed DLL which is not on your system (or incorrect version), can you see something in the windows event viewer (Windows -> Application logs) ? or try to run it from a seperate cmdline instance, maybe you then see some error message? or try to trace what files are tried to be loaded using procmon (from sysinternals).

In C#/,Net i (years ago) intercepted the DLL loads (long time ago), i could log them, and maybe (can't remember divert them). Within that method i could test versions (for win32 dll as for ".net assembly dll") and decline them. (Was nice back then to find out .Net searched DLL's in another place on devices with VisualStudio installed on them)

Move to a production Environment which is: - More affordable (read for more less expensive) - More supported - Far more developers worldwide - More 3th party components/development - Developed with a longterm vision, not a "grab as much money as you can" vision Only thing whats holding us back is the transition to a whole new environment, we probably should move from DB also (because we're "locked" to Interbase at the moment). But we'r getting there, more and more Management thinks with us, so gonna see wich new projects can be (partly) be done in a new development ecosystem. It's a pitty with me (with me Colllegue) think that Delphi (or better Pascal) is one of the most practical/readable dev languages whilest compiling one of the most fastes executables (win32). (I started with TurboPascal 5.5, good old times 🙂 ). The sneaky way how EMB moved the subscription from backwards support (whats was the promise when we started with it) to the only fixes in new releases (with new bugs) was/is really a stab in the back to developers. It's really a product of this century, "how to get as much out of our customers with the least effort", lock and squeeze. The example of not getting the LSP (codecompletion, error in sigth and others) in order in many years is the perfect example for this. Maybe it finally fixed in version 15.xxxx and we are tenthousands of dollars investment in the product (as customer) further down the road. Now i go back to work 🙂 , pretend to be happy with 11.3, which i have to start half of the times of his predecessor. [edit] It's a feeling like, paying for a new Mercedes E series but driving a 20year old Ford Ka.