Luiz Americo Pereira Camara wrote / napísal(a):
On 4/8/2011 09:21, LacaK wrote:
Is this branching somehow related to preparation of release some
next version of FPC (2.5.x ? or so) ?
I am asking because, there are waiting some bugs/features which I
would be happy see fixed before any major
Marco van de Voort wrote / napísal(a):
(or you are busy with other task and I must be patient and wait ;-))
I only cherry pick the easy db bugs to get some load of Joost. Typically
stuff where it is fairly clear what needs to be done, and no major design
decisions on fcl-db are taken.
That's why we have snapshots. The main purpose of a release is to have
something that is stable and which doesn't break previously working
code (except in known cases documented at
http://wiki.freepascal.org/User_Changes_Trunk ).
Are there published some rules, what breakage is acceptable,
My favorite is the really natural one: Plank-time count since the Big
Bang. Here supposedly we don't need negative values.,
Good joke! ;-)))
(but nobody knows, when it was (how many mld. years ago) and many
doubts, that it is real fact)
-Laco.
Felipe Monteiro de Carvalho wrote / napísal(a):
On Wed, Aug 3, 2011 at 6:55 AM, LacaK la...@zoznam.sk wrote:
So if this constant can not be changed, then I must write workaround for
date '01/01/0001' and do not add time part to this date.
The constant was already changed once
Is this branching somehow related to preparation of release some next
version of FPC (2.5.x ? or so) ?
I am asking because, there are waiting some bugs/features which I would
be happy see fixed before any major release.
Can I see somewhere on web some planed time schedule or anouncements
about
, dates 1 to 100AD are
already supported in FPC and no-one complayned about old databases in
the last years since the change made by Joost.
Lacak only asked to add 1 more day to our date limit.
Exactly so!
And MinDateTime is used only in these two conversions functions (to test
if result
I think there will be some RC1 or so in september.
Ok, so there is enought time before.
Can I post here list of registered bugs (fcl-db), which will be good
commit ?
(or you are busy with other task and I must be patient and wait ;-))
TIA
-Laco.
Jonas Maebe wrote / napísal(a):
On 02 Aug 2011, at 13:45, LacaK wrote:
What do you think, can we change MinDateTime from -693593.0 to
-693594.0;
(to accept 01/01/0001 23:59:59.999)
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg07989.html
Thanks, it seems, that Joost
Andrew Brunner wrote / napísal(a):
On Mon, Jul 11, 2011 at 3:02 AM, Mark Morgan Lloyd
markmll.fpc-de...@telemetry.co.uk wrote:
1.) Update Value : 40734.825668912039
2.) Actual Value after update : 40734.8256689120
3.) Actual Value on read :40734.825668912003
To not forget, I have reported it also in bug tracker
http://bugs.freepascal.org/view.php?id=19636
-Laco.
Hi Joost,
try attached patch. For me it works as expected.
-Laco.
Maybe someone else can.
If not, I think we should rewrite the whole function.
Joost.
Hi Joost,
try attached patch. For me it works as expected.
-Laco.
Maybe someone else can.
If not, I think we should rewrite the whole function.
Joost.
--- fmtbcd.pp.ori Mon Jun 20 07:10:16 2011
+++ fmtbcd.pp Mon Jun 20 07:51:26 2011
@@ -2205,8 +2205,6 @@ writeln;
Hi Joost,
for me:
100/1=10 --error
10/1=10
100/10=10
1000/1=10 --error
1000/10=10 --error
1000/100=10
100/2=50
1007/5=201.4
-Laco.
Hi all,
Dividing BCD's doesn't go wel:
100/1=10
100/2=overflow
1007/5=overflow
It's all in this function in the FmtBCD unit:
procedure BCDDivide ( const
Hi *,
I am now playing with test suite for fcl-db.
I encounter, that for every test in testfieldtypes.pas is repeatedly
called InitialiseDBConnector in toolsunit.pas (because of procedure
TTestFieldTypes.SetUp), which set-ups testValues and create instance of
TSQLDBConnector (which creates
Hi *,
I have 2 questions, which I divide into 2 emails.
1st is about TField.OldValue and Delphi compatibility. Please look at
small attached program (for SQLite3).
In Delphi (with TClientDataSet and dbExpress) outputs:
1. Field.OnValidate: OldValue=N; Value=N; NewValue=N
2. Field.OnChange:
This is second email. Can somebody confirm, that there is Access
Violation when we insert (or append) first row into empty dataset ?
(or I missed something?)
You can use attached program.
TIA
L.
program testOldValue;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
This is second email. Can somebody confirm, that there is Access
Violation when we insert (or append) first row into empty dataset ?
(or I missed something?)
You can use attached program.
Is the problem only with sqlite ?
No, I can reproduce it also for example with MySQL.
But exception is
Here is attached debug output with {$DEFINE DSDebug}.
It seems, that exception is related to Append/Insert (it does not depend
if dataset is empty before or not) followed by accesing OldValue
...
Setting current record to0
Post: Browse mode set
Active buffer requested. Returning:0
exception at
May be like this ?
Thanks.
Laco.
On Thu, 2011-06-09 at 11:49 +0200, LacaK wrote:
Here is attached debug output with {$DEFINE DSDebug}.
It seems, that exception is related to Append/Insert (it does not depend
if dataset is empty before or not) followed by accesing OldValue
Can't you
.
Michael.
On Thu, 9 Jun 2011, LacaK wrote:
May be like this ?
Thanks.
Laco.
On Thu, 2011-06-09 at 11:49 +0200, LacaK wrote:
Here is attached debug output with {$DEFINE DSDebug}.
It seems, that exception is related to Append/Insert (it does not
depend if dataset is empty before or not) followed
this error message isc_shutdown is throw during isc_attach_database and
so it seems, that your database is in shutdown mode
(which prevents you attach ... but I do not understand why you can
success fuly attach using ssh?)
See http://www.firebirdnews.org/?p=234
or better:
ftFmtBCD: begin
if P.AsFMTBCD.Precision 15 then //we are out of REAL range, so we
must bind as BLOB
begin
s tr1=BCDTOStrP.AsFMTBCD,SQLFormatSettings);
checkerror(sqlite3_bind_blob(fstatement,I,pcharstr(str1),
length(str1),
Hi Joost (and others also ;-),
I comment your question about
http://bugs.freepascal.org/view.php?id=18809 here.
(because I do not know what comment here and what in bug tracker)
I see problem in fact, that AsString returns number formated using
locale specific DecimalSeparator.
So if FmtBCD
I'll look at this solution. I'm a little bit confused about
SQLFormatSettings and why it was implemented as it is now. I'll have to
investigate this.
IMO for locale independent formatting numeric, date, time values
according to sql standard
or better:
ftFmtBCD: begin
if
Hi,
excuse me for this question ;-)
Closing bug report is task for reporter of bug or is not (so leave it
resolved and bug will close somebody later?) ?
Thanks
Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
/ Michael,
// do you plan do something else with this OnValidate problem ?
/
I thought I had done everything, or did I (again) forget something ?
There is IMHO unresolved original problem which is in fact,
that some TDataSet descendants implement call to Field.Validate in descendant's
Could I ask why is there needed VarDataInit ? (only for my interest ;-))
A good question. Formally it is not needed, but in general
initializing variables before use remains a good idea. Here the
TVarData is passed to VarDataCastTo, and after initializing we can be
sure that VarDataCastTo
Hi Sergei,
Sorry for the delay, got stuck with other issues... Applied in r17319.
Thank you for the patch!
It is ok ;-)
Thanks.
Could I ask why is there needed VarDataInit ? (only for my interest ;-))
Laco.
___
fpc-devel maillist -
Hi,
here are diffs with changes, I hope they will be good for all TDataSet
descendants (those specific to FPC and also those which are also for use
in Delphi)
Code which is general (and is used repeatedly) is placed in TField
methods and only small code remains which must be placed into each
Small optimalization use dsWriteModes instead of fixed set:
- if not (State in [dsEdit, dsInsert, dsFilter, dsCalcFields])
then //here should be IMO also dsNewValue
+ if not (FDataSet.State in dsWriteModes) then
DatabaseErrorFmt(SNotEditing,[FDataSet.Name],FDataSet);
--or--
introduce any new method (ValidateFieldData ? ;-))) and let tdatsset
descendants use it:
{$IFDEF FPC}
ValidateFieldData(Field: TField; Buffer: Pointer);
{$ENDIF}
--or--
some smarter solution ?
The whole code, which is repeated (and can be put in one place) is:
if not (State in
The whole code, which is repeated (and can be put in one place) is:
if not (State in [dsEdit, dsInsert, dsFilter, dsCalcFields]) then
begin
DatabaseErrorFmt(SNotEditing,[Name],self);
exit;
end;
if (Field.FieldNo0) and not (State in [dsSetKey, dsFilter]) then
begin
if Read
Running this code in Delphi 7 gives the exception below:
var
V: Variant;
D: TDateTime;
begin
ShortDateFormat := 'dd/mm/'; // the problem occurs regardless of
the format option
V := '20/04/2011';
D := V;
Memo1.Lines.Add('Date: ' + DateToStr(D)); // required to avoid dead
So, what should be done?
1) Be totally compatible with Delphi: convert date to string with
hardcoded format and raise exception when doing the conversion back?
2) Use the hardcoded format used to convert from vardate variant to
string and vice versa?
3) Use shortdateformat to convert from
Then please move approprate code at least into
TCustomBufDataset.SetFieldData
Thanks
This code was already there.
Should the 'Validate' code be moved there too ?
Yes. TDataset descendants are responsible to calling Validate, e.g.,
zeos call it inside TZAbstractRODataset.SetFieldData.
I
Hi,
This fix
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-db/src/base/fields.inc?r1=17199r2=17220
fixes mising call to TField.Validate (before data are written into
record buffer) and adds also call to TField.DataChanged (after data are
written)
But It seems to me, that
Simply said: So Sqlite doesn't support real BCD values.
Yes, SQLite does not support them native
So we can't support it either for Sqlite.
It was my question. We can (if we want) partialy add work-arounds:
DECIMAL(x,y)
if y=0 then map to ftLargeInt (64bit integer)
elseif y=4 then map to
No, map to ftfmtbcd, as it should. That will work fine as long as the
values are within the sqlite-range.
ok. in reading phase no problem
(ATM we read using sqlite3_column_text (so SQLite converts all storage
classes (integer,real, blob) to string) and then converting to TBCD ... ok
I have attached minor rearangement, consider them please
Will do. It's possible to go even further and completely exclude
finalization and try..finally block, because the intermediate Variant
is always of type Double, which doesn't need finalization.
Thanks!
I will look forward for your
Hi Sergei,
Doing what you propose isn't good. Checking for custom variant type
is expensive because it involves locking, therefore custom variant
handling should be done *after* the standard types.
Both committed in r17170, with some changes:
great thanks!
In fmtbcd.pp, I used
Hi,
after doing some test with new implementation of TFmtBCDField for
TSQLite3Connection connector I encounter this problem:
When you declare in SQLite some column as NUMERIC or DECIMAL then this
column will have NUMERIC affinity.
CREATE TABLE t (d DECIMAL(30,7));
If you insert in such
Hi,
I would like ask for your opinion in this case.
I found, that in this sample program is raised Invalid variant ...
var bcd1: TBCD;
v,v1: variant;
s: string;
begin
bcd1:=2;
v1:=varfmtbcdcreate(bcd1);
s:=v1; //assigment from customvariant to string is not handled in
Hi Sergei,
I can fix it by following fixs:
1. fmtbcd_castto.diff ... added case when castto varString is
requested ... then do not use cast throught varDouble (to avoid lost
of precision), but convert directly from TBCD to string
2. variants.pp ... here we must add handling of
Hi,
I would like to ask somebody to look at these bug reports:
1. http://bugs.freepascal.org/view.php?id=18388
This bug report contains implementation of missing BcdToStrF function.
There is also discussion if FmtBCD unit is localized ... tests under
Delphi (6,10) shows, that Delphi *uses*
One way is: TField.Size := (TFieldDef.Size div 2) if it's a WideString,
and div 4 if unicode is enabled. Or the TDataset descendant has to
correct the value for WideStrings when creating fields. (How?)
Very simple/primitive Idea No1:
add property DataSize: integer read GetDataSize write
Hi,
I am writting here to discuss bug
http://bugs.freepascal.org/view.php?id=17268
(I do not want reopen bug and writte there because I am not sure
about my arguments)
IMHO root of problem is in different definition of TFieldDef.Size and
TField.Size
Documentation says, that
1.
Please, be patient. I'm working on it, as you can see in the bug reports
and commits.
ok, of course
I did not know your plans, ideas, thoughts etc.
As I said earlier, widestringfields aren't available in fpc yet. Someone
wrote some code for it, but it is never properly tested and probably
I'm adding some ftTime tests.
Did you noticed, that I already posted such tests
http://bugs.freepascal.org/view.php?id=18763 ?
Then let me know, I send you fix for ftTime for TODBCConnection ... but
depends on http://bugs.freepascal.org/view.php?id=18773
All widestring-issues are
Hi,
we have in fcl-db TField.AsBCD: TBCD; but we do not have TParam.AsBCD,
nor TParam.AsFMTBCD
Delphi defines:
TParam.AsBCD: Currency ...
http://docwiki.embarcadero.com/VCL/XE/en/DB.TParam.AsBCD
TParam.AsFMTBCD: TBCD ...
http://docwiki.embarcadero.com/VCL/XE/en/DB.TParam.AsFMTBCD
But for me
Ok, here is patch for AsFMTBCD: TBCD ...
http://bugs.freepascal.org/view.php?id=18809
Please review.
It seems, that methods TParam.GetData and SetData are not used at all
... strange ;-)
Laco.
Well, the Delphi compatible way is usually preferred.
It makes no sense to have both .asBCD and
Hi,
can anybody look into dsparams.inc at above mentioned method.
There are using 5 assigments : DataType := ...
1. because DataType is property it uses SetDataType method
2. SetDataType method try convert existing FValue into new FieldType
3. but later in AssignFieldValue is FValue rewritten by
Hi,
I am writting here to discuss bug
http://bugs.freepascal.org/view.php?id=17268
(I do not want reopen bug and writte there because I am not sure about
my arguments)
IMHO root of problem is in different definition of TFieldDef.Size and
TField.Size
Documentation says, that
1.
Hi Joost,
thanks!
Thinking about TFmtBCDField it seems to me, that also dsparams.inc must
be adjusted to support ftFMTBcd ... add AsBCD: TBCD etc. ... at least my
test with new TSQLite3Connection shows, that there is missing it (when
applyng updates to record)
Do you have already finished
Hi Joost,
it seems, that you have started applying patch in
http://bugs.freepascal.org/view.php?id=18160 or
http://bugs.freepascal.org/view.php?id=16924
Great!
I have some comments, ideas, please consider them.
Because in mean time was enhanced FmtBCD unit you can remove some
commented lines
Hi *,
there are some waiting bugs with patches, which are relative simple and
IMHO they can not affect negatively product quality.
I summarize them here, for quick review them, so if then they can go
into 2.4.4 release:
1. http://bugs.freepascal.org/view.php?id=17188 and
They all need improvement or a better review or testcases or break
backwards compatibility.
The BIGINT or NCHAR stuff not, I would think ?
I'll have a look.
BIGINT leads to a backwards compatibility issue with largeint not being
recognized anymore. (not a real problem I think,
Michael can you please look also at this
http://bugs.freepascal.org/view.php?id=17510
Thanks
Laco.
I will look at them today.
Michael.
On Wed, 16 Feb 2011, LacaK wrote:
Hi *,
there are some waiting bugs with patches, which are relative simple
and IMHO they can not affect negatively
Hi Joost,
thanks for reply
4. http://bugs.freepascal.org/view.php?id=14944
This fix adds support for transactions in ODBCConnection
Adding transactions so close to a release is not a good idea, imho. It
could be added in trunk, though.
ok, no objections from me side
only to explain:
When I already have start this thread, I would like also point to this
bugs (their are both more or less about the same):
http://bugs.freepascal.org/view.php?id=14730
http://bugs.freepascal.org/view.php?id=18162
Now I can not primary talk about NULL paramters, but about ukInsert case
(in
Hi *,
consider following sample program:
var
b: array[0..255] of char;
begin
if getlocaleinfoa(LOCALE_USER_DEFAULT, LOCALE_SSHORTDATE, b,
sizeof(b)) 0 then
writeln('LOCALE_USER_DEFAULT:',b);
if getlocaleinfoa(LOCALE_SYSTEM_DEFAULT, LOCALE_SSHORTDATE, b,
sizeof(b)) 0 then
Please file a bugreport, citing the stackoverflow answer.
http://bugs.freepascal.org/view.php?id=18574
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
If sb wants in in 2.4.4, I urge you to be quick :-)
Does it mean, that you are preparing release 2.4.4 in short time ?
If yes, then I would happy, if also bug
http://bugs.freepascal.org/view.php?id=16493 with attached patch will be
commited.
Thanks
Laco.
Done. Revision 16776.
Thak you very much.
Could I ask how/when are bugs/patch reviewed/commited ?
Is there any single person(s) who maintains for example fcl-db or any
fpc-developer can apply patches ?
Is there any special time when patches are applied or in trunk can be
patch applied any
So IMHO there must be:
1. allocated space in record buffer in size 4*TFieldDef.Size+1
2. redefine meaning of Size property (as number of bytes not
characters) and create fielddefs with Size*4
Yes, those are the possible solutions. Good thing about the second
option, is
So this is answer, which i have looked for:
In Lazarus TStringField MUST hold UTF-8 encoded strings.
Not entirely true. You could also choose to bind the fields to some
Lazarus-components manually, not using the db-components.
IMHO most of gui database applications use controls like
Didn't I explain this to you and others a few times?
;-) If so, then please excuse me
The database-components itself are encoding-agnostic. This means:
encoding in = encoding out.
So it is up to the developer what codepage he want to use. So
TField.Text can have the encoding _you_ want.
Joost van der Sluis wrote / nap?sal(a):
On Wed, 2011-01-12 at 14:59 +0100, LacaK wrote:
No. It is mandatory that you send/receive UTF8 to/from GUI LCL
elements.
As LCL elements are using TStringField.Text property, then this property
should return UTF8String, right (not AnsiString
L Yes in UNIX world it may be so (I do not know),
L but in Windows ODBC we have no such possibility AFAIK
Quote from Microsoft:
The ODBC 3.5 (or higher) Driver Manager supports both ANSI and
Unicode versions of all functions that accept pointers to character
strings or SQLPOINTER in their
Most probably it needs a flag to indicate that the ODBC must work in
Unicode, and then dynamic link to *W functions if this flag is set. I
think ODBC drivers since 2002+/- should have this set of APIs, but I
had never used ODBC in my life... :)
It seems, that Driver Manager automaticaly
Sven Barth wrote / napísal(a):
Am 12.01.2011 07:16, schrieb LacaK:
P.S. I still does not understand, how can things work correctly if LCL
expect that all AnsiStrings (String) are UTF8Strings, byt RTL/FCL does
not strictly follow this (at least in Windows) ?
LCL uses SysToUTF8 and UTF8ToSys
L 2. Is it wrong in implementation of TSQLConnectors, which write data
L into record buffer (of TStringField) and do not convert them always into
L UTF-8 ?
Do you set the CHARSET field in your TSQLConnector to UTF-8 ?
not all connectors supports CharSet property. When I look into sources
only
This was discussed few times here. Later ppl tired from the endless
discussions and summarised their ideas on this page:
http://wiki.lazarus.freepascal.org/Modernised_Pascal
Nice!
For me, If I can say is most interested:
1. try ... except ... finally ... end;
2. C style IIF operator: l ?
Martin Schreiber wrote / napísal(a):
On Wednesday, 12. January 2011 09.45:47 LacaK wrote:
So where is error ?
1. Is it wrong expectation by LCL, that TField.Text is always UTF8 string
-or-
2. Is it wrong in implementation of TSQLConnectors, which write data
into record buffer
L but db client library api, which is used by SQLConnector to
L retrieve data.
How an UTF8 SQLConnector can retrieve UTF8 data from a field defined
as binary ?
It cann't .
Here I am speaking about TStringField, which is IMHO designed for
character data, for binary data is designed
I think at most two are required for any target: unicodestring (D2009
compatibility), and if really necessary because somehow the unicodestring
version causes too much overhead, an ansistring($) version as well. That's
only for the classes though, I think most of the base RTL can be
...: the new ansistring type has a hidden element size field (in
addition to the reference count, length and codepage), and from what I
can see at page 10 of
http://edn.embarcadero.com/article/images/38980/Delphi_and_Unicode.pdf,
Delphi 2009's unicodestring is simply an ansistring(1200).
Hi *,
In current Delphi is String synonym for base type UnicodeString UTF-16
AFAIU ATM in FPC is String synonym for AnsiString (as in previos
versions of Delphi)
Are there any plans to change meaning of String type ?
(like Delphi to UnicodeString , or UTF8String?)
Are there any plans to
AFAIK, in current Delphi (which I don't have) a String is a variable
that can contain dynamically coded informations (such as locally
coded 8-Bit ANSI, UTF-8, UTF-16, ...) and - of course - know which
code it holds.
I understand By default, variables declared as type String are
101 - 178 of 178 matches
Mail list logo