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
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).
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
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
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
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
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
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 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 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,
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,
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
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 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*
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 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
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
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
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
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
--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
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);
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
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 -
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
/ 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
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
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
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),
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
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
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 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 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;
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.
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
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
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.
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,
Michael Van Canneyt wrote / napísal(a):
On Mon, 15 Aug 2011, LacaK wrote:
Hi,
it seems, that there is ATM no versions of StrCopy, StrLCopy, which
works with WideChars (in SysUtils).
Can these variants be added ?
function StrCopy(Dest: PWideChar; const Source: PWideChar): PWideChar;
http
Hans-Peter Diettrich wrote / napísal(a):
LacaK schrieb:
Or do you not like these wide versions at all ?
It's not a matter of liking, I'm afraid. If Delphi has them, we'll
have to add them too :-)
Can you please add an entry in the bug tracker, so we don't forget ?
http
Hi,
I encounter strange thing. Look at this program please:
var
LibraryHandle: TLibHandle;
cw: word;
begin
cw:=Get8087CW;
writeln('CW before:',cw, ' IntPower:', intpower(10,-6));
LibraryHandle:=LoadLibrary('odbc32.dll');
writeln('CW after:',Get8087CW, ' IntPower:', intpower(10,-6));
Because of no response I registered it as bug
http://bugs.freepascal.org/view.php?id=20011
Can you please look at least at this:
Which compiler defines are OK ? i386 or cpui386
My test shows, that i386 is NOT defined (cpui386 IS defined), but
then I do not understand how can it work in
Thank you!
Off-topic: It seems, that in my case (in ibase60.inc is used: uses
Dynlibs, sysutils,ctypes; ) function SafeLoadLibrary defined in
SysUtils hides SafeLoadLibrary used in DynLibs, this is reason, why
SafeLoadLibrary worked as expected.
So is i386 obsolete ?
If yes there are other
Hi,
I found this it fpc-pascal mailing list archive (I do not read this mailing
list, so I do not catch this discussion)
Because I think it is worth to continue, I move it into fpc-devel
/ ... I feel the definition
// of SetFieldData/GetFieldData without a length/size parameter
// and strings
Florian Klämpfl wrote / napísal(a):
Am 16.08.2011 07:06, schrieb LacaK:
Hans-Peter Diettrich wrote / napísal(a):
LacaK schrieb:
Or do you not like these wide versions at all ?
It's not a matter of liking, I'm afraid. If Delphi has them, we'll
have to add them
Joost van der Sluis wrote / napísal(a):
On Sat, 2011-09-17 at 10:56 +0200, Michael Van Canneyt wrote:
On Sat, 17 Sep 2011, Martin Schreiber wrote:
Hi,
TField.SetData() in fixes_2_6 calls TField.Validate().
2.4.4 does not, trunk neither.
Strange that 2.6 does this if trunk
Did anyone recently do work on BLOB features to MySQL 5.1 connector?
there was commited only this
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-db/src/sqldb/mysql/mysqlconn.inc?r1=17417r2=18951
which introduced mapping from MySQL TEXT datatype (character LOB) to
And which SQL DBConnector do you use ?
TMySQL51Connection ?
my app maps this particular field as SQL_LONGVARBINARY
or TODBCConnection ?
L.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Martin Schreiber wrote / napísal(a):
On Friday 23 September 2011 14.00:07 Sergei Gorelkin wrote:
Recently strings behavior was changed, they are now codepage-aware. The
compiler can now implicitly convert strings from one encoding to another.
To handle non-string data, you should use
Are there available Lazarus snapshots, which are build using current trunk ?
If I download Lazarus with FPC 2.7.1 ( for example:
ftp://www.hu.freepascal.org/pub/lazarus/snapshots/Lazarus-0.9.31-33000-fpc-2.7.1-20111021-win32.exe
)
it seems, that there are not current source files from trunk,
Hi,
I am now working on fcl-db TBinaryField, which has Value: Variant property.
As I understand documentation, this variant should be returned as
variant array of bytes.
Later when are assigning values of fields into params also this variant
array is copied (into TParam).
But when I
Hi Sergei,
Thank you for your reply.
As it is out of my comfort zone, I leave it to up to you (if or when you
implement this)
TIA
-Laco.
It has to be done in a different and more complex way, by using VariantChangeTypeEx to convert the
variant(array) to varOleString type, then converting
May be that is is (or not ;-)) related to
http://bugs.freepascal.org/view.php?id=17360
-Laco.
Hello, this is my first post and I hope this is the correct list for
my question.
I'm getting a segmentation fault ('violación de segmento' in spanish)
when running the code from below on a Linux
for new stuff ;-)
6. if there is any problem please let us know. If you decide to include
it into fcl-db then you can place files for example into src/sqldb/mssql
folder ;-)
TIA
-Laco.
Hi,
As you can see here http://bugs.freepascal.org/view.php?id=17303 the
developer known to LacaK developed a new
Hi *,
I found small incompatibility between Delphi and FPC.
This code:
var a,b: array of byte;
begin
setlength(a,2);
b:=copy(a,2,1); //--HERE Range check error in FPC, Delphi
returns empty array
end;
Delphi documentation says:
If Index is larger than the length of S, *Copy* returns an
Sergei Gorelkin wrote / napísal(a):
29.02.2012 17:05, Sven Barth пишет:
It's not a bug in Delphi if they write it in the documentation.
Whether we should copy this behavior
is the question (maybe only in Delphi mode).
It cannot be fixed for Delphi mode only because a single copy of RTL
is
Sergei Gorelkin wrote / napísal(a):
29.02.2012 18:21, LacaK пишет:
It cannot be fixed for Delphi mode only because a single copy of RTL
is used for all compiler modes.
The current situation where out of range 'length' parameter is
adjusted but 'index' out of range
raises exception is simply
michael.vancann...@wisa.be wrote / napísal(a):
On Thu, 15 Mar 2012, Marcos Douglas wrote:
On Mon, Feb 27, 2012 at 9:33 AM, Marcos Douglas m...@delfire.net wrote:
On Mon, Feb 27, 2012 at 5:08 AM, michael.vancann...@wisa.be wrote:
On Mon, 27 Feb 2012, LacaK wrote:
Hi,
let me share same
Hi Michael,
splitting files into two packages was unavoidable?
Yes.
As you can see for the other databases, we always keep the header
imports separate from the components. Standard time-tested practice.
Hm, although I am not happy with this, I can do nothing with it ;-)
Then I have minor
No.
Anyway, I change the colum names (id,name to col1, col2)
The error is:
Cannot insert the value NULL into column 'col', table tempdb.dbo.#t...
This error has nothing to do with FPC or SQLDB.
Your SQL statement is trying to insert NULL in a required field.
No Michael, see
1 - 100 of 178 matches
Mail list logo
