Dmitry Arefiev

Request must contain valid Accept header, then RAD Server will choose the correct endpoint. If there is no Accept, or it is not unique identifying endpoint, then above error is returned. Check what your browser is sending in request Accept headers.

try var LURI := TURI.Create(AURI); Result := True; except Result := False; end;

Please report that to quality.embarcadero.com and provide simple test application to reproduce the issue. Without details / code hard to say anything ...

http://docwiki.embarcadero.com/RADStudio/Sydney/en/Configuring_Drivers_(FireDAC)

@bazzer747, if you think there is an issue, please post your report to quality.embarcadero.com. And attach to your issue: FireDAC environment report - http://docwiki.embarcadero.com/RADStudio/Sydney/en/DBMS_Environment_Reports_(FireDAC)#Using_Delphi_Code small test application reproducing the issue. PS: It should work ...

You should understand what all these redirections are: if this is endless loop of redirections, then many options: fix the server logic; use different URL; provide additional headers (eg authentication); etc if this is long chain of redirections, then set MaxRedirects to a higher value.

VCL or FMX ? If VCL, then: NumberBox1.Mode := nbmCurrency; NumberBox1.Decimal := 0; NumberBox1.CurrencyString := 'pixel'; NumberBox1.CurrencyFormat := 3; // etc, eg MinValue=0, MaxValue=1500

SQLite is really typeless database. When you use AOutput.AsCurrency, then FireDAC maps this to SQLITE_TEXT (to keep precision), and AOutput.AsFloat to SQLITE_FLOAT. To "remap" an expression in SELECT list to a Delphi specific type you should use special construction in SELECT list: <expression> AS "<alias>::<type>" More about that: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_SQLite_with_FireDAC#Adjusting_FireDAC_Mapping

This is a bug in TFDBatchMoveTextReader. To fix it: open FireDAC.Comp.BatchMove.Text.pas locate there lines (around line # 1750): until FEof or lEOL or not lInDelim and (FBuff[iLen] = DataDef.Separator); if not FEof then Dec(iLen); replace with: until FEof or lEOL or not lInDelim and (FBuff[iLen] = DataDef.Separator); if not FEof or not lEOL then Dec(iLen); add FireDAC.Comp.BatchMove.Text.pas to your project, or include path to this unit to project->options Search Path, or to tools->options Library Path PS: Best will be to report this issue to quality.embarcadero.com

http://docwiki.embarcadero.com/Libraries/Sydney/en/FireDAC.Stan.Option.TFDFormatOptions.InlineDataSize

Fixed. Changes will be in 10.4 Update 2.

Yes, please.

Ok, I reproduced your issue after modifing your failing query in second post to: select * from FDMemTable1 where Field_1 like :Param_B or Field_2 like :Param_B or Field_3 like :Param_B

I cannot reproduce the issue using 10.4.1. Could you please post: 1) Your RAD Studio version 2) Simple test project reproducing the issue

1) Please post FireDAC environment report for your connection: http://docwiki.embarcadero.com/RADStudio/Sydney/en/DBMS_Environment_Reports_(FireDAC)#Using_the_TFDConnection_Design_Time_Editor 2) Can you attach one of the DB files ?

In the plan is to check latest MS SQL ODBC driver, and update FireDAC MSSQL driver if needed. No plans for OLEDB support. Just no sense ...

http://docwiki.embarcadero.com/RADStudio/Sydney/en/Local_SQL_(FireDAC)

No way.

FireDAC in 10.4.1 uses SQLite 3.31.1. But IIF was added in 3.32. Instead you can use FireDAC macro function: {IIF(....)}: http://docwiki.embarcadero.com/RADStudio/Sydney/en/System_Macro_Functions_(FireDAC)

You mean, that each FDQuery will get own connection from pool ? If yes, then this will lead to a lot of issues ...

When FDQuery's use ConnectionName, then single temporary TFDConnection will be created transparently and used by all FDQuery's, etc

FireDAC TFDTable emulates BDE/Paradox TTable behavior using LDW mode. This is expensive, and disabling LDW mode will improve performance. More info: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Browsing_Tables_(FireDAC) But anyway, you will never get 100% similar performance to BDE/Paradox TTable with big tables. Any TxxxTable will request DB server and will fetch the data. When data is fetched, then operations will be fast and similar to TTable.

Yes, it is. But you can use always full object (table) name.

Other option is to use TFDManager.CloseConnectionDef http://docwiki.embarcadero.com/RADStudio/Sydney/en/Multithreading_(FireDAC)#Connection_Pooling

FDManager.Active := False; // change what you need