search

nakijun / txquery

Automatically exported from code.google.com/p/txquery
Other
0 stars 0 forks source link

Updated and improved Sources Of TXQuery 2013-05-15, (based on rev. 2012-10-11 by cychau) [Posted HERE] (Added Full Unicode support) #40

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Hi Guys, I have Uploaded a new modified  version. this make a lot changes to 
the sources. mainly for the puprose to add full unicode support of TXQuery, at 
least for Unicode IDEs (2009 an up).

I have a added full support for Unicode in TXQuery, now you can also add 
unicode chars to the SQL script, an the parse will manage it gracefully.

so you can add something like:

SELECT field1, field2, field3, ('รหัสสินค้า'+'  => 
'+field3) as UnicodeField3
FROM
 table1
WHERE field3 = 'ěščřžýáíé';

--------------------------------------------------------------------
--NOTES Regarging NON Unicoe IDEs:
I have also made a lot of changes to add uniode support to NON Unicode IDES 
(delphi 2007 and older) via the use WideStrings. I cannot validate this changes 
because for now I don't have an IDE installed for those compilers.

Please feel free to test them, they should work.

In the x_flag.inc there is a compiler definition 

{.$DEFINE XQ_USE_WIDESTRINGS}

This is for the NON unicode compilers, Please enable it by removing the '.', 
This will force the compiler to use WideStrings instead of AnsiStrings. 

When this define is disabled, the widestrings are still managed but only via 
the data contained in the fields, the SQL script will be ANSI so, you cannot 
put Unicode Chars in the SQL script, But any Unicode data contained in your 
Datasets should be managed correctly.

I have fully tested this in Delphi XE, and should work correctly in Unicode 
compilers (D2009 and up).

Some TXQuery Events would change if you force the use of WideStrings, so I 
recommend to do the corrections, By default Those AnsiString Fields will be 
changed to WideString and the TStringList will be changed to TWideStringList.

The changes were made to these events:
OnUDFCheckEvent
OnUDFSolveEvent
OnIndexNeededForEvent
OnSetRangeEvent
OnSetFilterEvent
OnCreateIndexEvent
OnDropTableEvent
OnDropIndexEvent
OnSyntaxErrorEvent
OnResolveDatasetEvent
OnQueryFieldNameEvent
OnSetUserRangeEvent

If you use in your code one or more of these events, You will have to copy the 
code you PUT there, Remove the event and recreate it, then Paste again the code 
you used in that event. This change have to be done only when you FORCE the use 
of WideStrings with Delphi 2007 and older compilers.

For further changes you can ADD a compiler condition in the method definition 
of the event, so it wont be affected when you migrate to a newer IDE (Unicode) 
or remove the forced use of WideStrings, 

Example:

procedure XQuery1ResolveDataset(Sender: TObject;
      const Filename: {$IFDEF XQ_USE_WIDESTRINGS}WideString{$ELSE}String{$ENDIF};
      var ATableName: {$IFDEF XQ_USE_WIDESTRINGS}WideString{$ELSE}String{$ENDIF};
      var Dataset: TDataSet);

procedure XQuery1CreateIndex(Sender: TObject; Unique, Descending: Boolean; 
const TableName,
      IndexName: {$IFDEF XQ_USE_WIDESTRINGS}WideString{$ELSE}String{$ENDIF};
      ColumnExprList: {$IFDEF XQ_USE_WIDESTRINGS}TWideStringList{$ELSE}TStringList{$ENDIF});

procedure XQuery1IndexNeededFor(Sender: TObject; DataSet: TDataSet;
      const FieldNames: {$IFDEF XQ_USE_WIDESTRINGS}WideString{$ELSE}String{$ENDIF}; ActivateIndex, IsJoining: Boolean;
      var Accept: Boolean);

Don't forget to Include the 'XQ_Flag.inc' file at the begining of your .pas 
form unit and in any unit where you use the XQ_USE_WIDESTRINGS definition, so 
the compiler definition can be evaluated correctly

This will make you code adaptable to any Delphi version.
REMEMBER This is only needed when working with delphi 2007 and older compilers
-------------------------------------------------------------------

Regards and have fun

Original issue reported on code.google.com by fdue...@gmail.com on 16 Apr 2013 at 3:07

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Just a little tip:

In this new version I have optimized the Size of the resulting String and 
Widestring fields.

Before this optimization, the resulting field size was the SUM of the size of 
each expression and source field. So if you have a resulting string field that 
is the concatenation of three string fields, and each source field's size was 
of 100 (TFields' size property), even if the data doesn't contain that amount 
of chars, the resulting field would have the size of 300, now with this 
optimization the size will be the Max size of the String expression obtained 
from the concatenation.

This optimizations could lead you to some problems if you manage Persistent 
fields in TxQuery components, so if you don't want to have problems with memory 
leaks, AVs, or any other strange behavior you should do one of the next two 
things:

a) Delete and recreate your persistent fields contained in every TxQuery 
component.
or
b) Comment or delete the Compiler definition {$DEFINE 
XQ_USE_OPTIMIZED_STRING_FIELD_SIZE} located in XQ_Flag.inc and recompile 
TxQuery. This will leave the old method active.

Original comment by fdue...@gmail.com on 24 Apr 2013 at 10:58

GoogleCodeExporter commented 9 years ago 
Thanks for the tip!

I don't use any persistent fields with TxQuery. I just use TxQuery a 
TQuery against TkbmMemTables. I have quit using kbmMemSQL for now 
because it still has many problems that I don't have time to address 
right now!

Thanks again!

Shane

Original comment by Sh...@StumpWare.com on 24 Apr 2013 at 11:29

GoogleCodeExporter commented 9 years ago 
Minor bug fixes reported by Shane Stump.

FIXED: parser throw exceptions with 'IS NULL' and 'IS NOT NULL', they sometimes 
didnt return a boolean result.

Many thanks Shane

Original comment by fdue...@gmail.com on 25 Apr 2013 at 4:39

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Fully Fixed Delphi 2007 compilation, added Xe4 support.

Original comment by fdue...@gmail.com on 23 Jul 2013 at 9:19

Attachments:

GoogleCodeExporter commented 9 years ago 
Fixed INSERT statement issues

Original comment by fdue...@gmail.com on 24 Jul 2013 at 7:21

Attachments:

GoogleCodeExporter commented 9 years ago 
Fails to Compile in XE4 !?

Best regards
Branko

Original comment by branko.b...@gmail.com on 25 Jul 2013 at 2:45

GoogleCodeExporter commented 9 years ago 
Branko, you may download a TxQuery 3.0 beta release to try first.

Original comment by cychau on 25 Jul 2013 at 10:52

GoogleCodeExporter commented 9 years ago 
Hello Cychau,

Yes, your sources compile ok with some warnings (mostly deprecated ...).

Your sources are significantly different then fdue...'s. Each of you develops 
its own version ?

TIA and best regards
Branko

Original comment by branko.b...@gmail.com on 26 Jul 2013 at 10:22

GoogleCodeExporter commented 9 years ago 
Hi Branko,

We are in the merging process.  TxQuery 3.0 is going to release soon.

Original comment by cychau on 26 Jul 2013 at 1:02