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, se
I wonder about much code in the RTL/FCL, that depends on String type
arguments, like:
Procedure TStream.WriteAnsiString (const S : String);
Var L : Longint;
begin
L:=Length(S);
WriteBuffer (L,SizeOf(L));
WriteBuffer (Pointer(S)^,L);
end;
This method will work only as long as
On Tue, Mar 20, 2012 at 8:12 PM, wrote:
>
>
> On Tue, 20 Mar 2012, Marcos Douglas wrote:
>
>> On Tue, Mar 20, 2012 at 6:59 PM, Michael Van Canneyt
>> wrote:
>>>
>>>
>>>
>>> On Tue, 20 Mar 2012, Marcos Douglas wrote:
>>>
No.
Anyway, I change the colum names (id,name to col1, col2)
On Tue, 20 Mar 2012, Marcos Douglas wrote:
On Tue, Mar 20, 2012 at 6:59 PM, Michael Van Canneyt
wrote:
On Tue, 20 Mar 2012, Marcos Douglas wrote:
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.
On Tue, Mar 20, 2012 at 6:59 PM, Michael Van Canneyt
wrote:
>
>
> On Tue, 20 Mar 2012, Marcos Douglas wrote:
>
>>
>> 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 not
The buildfaq claims that OPT= will add parameters to every compiler
commandline. Unfortunately it doesn't seem to actually do that. The
options are added when building the compiler and RTL but it seems they
aren't added when building fpmake.
This is a problem for me as to successfully build fp
On Tue, 20 Mar 2012, Marcos Douglas wrote:
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 re
2012/3/20 Marcos Douglas :
> On Tue, Mar 20, 2012 at 5:57 PM, silvioprog wrote:
>> This error occurs to me too. Please see this video:
>>
>> http://silvioprog.com.br/video/bug/sqldb
>>
>> Lazarus 0.9.30.4 r35940 FPC 2.6.0 i386-win32-win32/win64 + openSUSE 12
>> / Windows 7 + PQConnection + Postgre
On Tue, Mar 20, 2012 at 5:57 PM, silvioprog wrote:
> This error occurs to me too. Please see this video:
>
> http://silvioprog.com.br/video/bug/sqldb
>
> Lazarus 0.9.30.4 r35940 FPC 2.6.0 i386-win32-win32/win64 + openSUSE 12
> / Windows 7 + PQConnection + PostgreSQL 8.4.
Silvio,
Thanks for the vi
This error occurs to me too. Please see this video:
http://silvioprog.com.br/video/bug/sqldb
Lazarus 0.9.30.4 r35940 FPC 2.6.0 i386-win32-win32/win64 + openSUSE 12
/ Windows 7 + PQConnection + PostgreSQL 8.4.
--
Silvio Clécio
Site -
LazSolutions -
On Tue, Mar 20, 2012 at 4:00 PM, Michael Van Canneyt
wrote:
>
>
> On Tue, 20 Mar 2012, Marcos Douglas wrote:
>
>
> Hi Michael,
> Do you have some prediction to include the sources?
My apologies, I had totally forgotten; I am buried in work currently.
I can now successfully pass doubles to/from C functions on armhf. I've
written a test program that passes lots of different combinations of
single/double/longint/int64 to C code and all combinations that do not
involve singles are working.
It would also be helpful to add this test to th
peter green wrote:
The bad news is that a number of testcases are still failing. Next on
my list is 16 singles.
Ok that was easy, a small logic flaw in my code was preventing a
parameter being correctly assigned to the last available single
precision register when it should have been. And with
On Tue, 20 Mar 2012, Marcos Douglas wrote:
Hi Michael,
Do you have some prediction to include the sources?
My apologies, I had totally forgotten; I am buried in work currently.
Committed in revision 20522. I didn't commit any examples or tests. Please
test if everything works OK. I compi
On Fri, Mar 16, 2012 at 9:55 AM, Marcos Douglas wrote:
> On Fri, Mar 16, 2012 at 5:40 AM, wrote:
>>
>>
>> On Thu, 15 Mar 2012, Marcos Douglas wrote:
>>
>>> On Mon, Feb 27, 2012 at 9:33 AM, Marcos Douglas wrote:
On Mon, Feb 27, 2012 at 5:08 AM, wrote:
>
>
>
> On Mon,
>
> Done http://bugs.freepascal.org/view.php?id=21516
Patch attached to mantis.
Ludo
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 20/03/2012 12:55, Ludo Brands wrote:
typelib.pas(1353,48) Error: range check error while
evaluating constants
(-1 must be between 0 and 4294967295)
Can you raise a mantis issue? I'll fix this. According to msdn
http://msdn.microsoft.com/en-us/library/cc237755%28v=prot.10%29.aspx the
function
> Compiling .\winunits-base\src\typelib.pas
> typelib.pas(371,71) Hint: Local variable "Handle" does not seem to be
> initialized
> typelib.pas(493,33) Hint: Local variable "sl" does not seem to be
> initialized
> typelib.pas(562,48) Hint: Local variable "sMethodName" does
> not seem to
> be in
on Win 32
Compiling .\winunits-base\src\typelib.pas
typelib.pas(371,71) Hint: Local variable "Handle" does not seem to be
initialized
typelib.pas(493,33) Hint: Local variable "sl" does not seem to be
initialized
typelib.pas(562,48) Hint: Local variable "sMethodName" does not seem to
be initia
On 20 Mar 2012, at 12:29, Paul Ishenin wrote:
20.03.12 19:02, Jonas Maebe написал:
That's of course a very old version of gdb (some fork based on
6.3.50),
so maybe it's a regression.
As I remember this was fixed in fpc trunk only?
That was something else. It works fine if I compile the
20.03.12 19:02, Jonas Maebe написал:
That's of course a very old version of gdb (some fork based on 6.3.50),
so maybe it's a regression.
As I remember this was fixed in fpc trunk only?
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@
On 19 Mar 2012, at 16:37, Martin wrote:
Dwarf (see below) everything seems to be public:
Dwarf does not seem to show methods
With gdb on Mac OS X it works fine (and yes, this is DWARF):
(gdb) ptype TLINKEDLIST
type = ^TLINKEDLIST = class : public TOBJECT
private
FCOUNT : LONGINT;
F
On 20/03/2012 07:41, Paul Ishenin wrote:
20.03.2012 15:39, Graeme Geldenhuys написал:
Maybe I'm not understanding this correctly, but why would you want
"visibility restrictions" on debug information? Surely when debugging,
you want access to ALL data - thus public visibility across the board
se
20.03.2012 15:39, Graeme Geldenhuys написал:
Maybe I'm not understanding this correctly, but why would you want
"visibility restrictions" on debug information? Surely when debugging,
you want access to ALL data - thus public visibility across the board
seem good.
Obviously - to show the visibil
On 19 March 2012 17:37, Martin wrote:
>
> Dwarf (see below) everything seems to be public:
Maybe I'm not understanding this correctly, but why would you want
"visibility restrictions" on debug information? Surely when debugging,
you want access to ALL data - thus public visibility across the boa
25 matches
Mail list logo
