Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Tue, 20 Mar 2012, Marcos Douglas wrote:
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)
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 the example I wrote before.
I saw the example :-)
Create table:
create table #t (col1 int, col2 varchar(60))
OBS: No column is required.
This INSERT works:
insert into #t values (1, 'bla bla bla')
This INSERT do NOT works:
insert into #t (col2) values ('bla bla')
This kind of SQL is passed as-is to MSSQL. To my knowledge, SQLDB does not
change it.
If you had been using parameters, it would have been a different story.
Does matter if I use or not parameters.
Yes, of course. In that case, SQLDB does some preprocessing of your SQL
statement.
This can easily be checked. Try setting ParamCheck to 'False' before
executing your statement.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] What's the state of "string"?
On Wed, 21 Mar 2012, Hans-Peter Diettrich wrote:
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 String=AnsiString, because Length
*bytes* are written, not *chars* of a possibly different byte count.
Is the use of generic types, like String, really okay in the library code,
when the concrete type matters?
No. This work still needs to be done.
The documentation on strings (3.2 Character types) is not really helpful,
most entries look like they deserve an update reflecting the role of
UnicodeString and the generic String type, and implicit string conversions.
In detail I miss instructions on how to determine or specify the String type,
with different FPC versions.
{$H} is documented, {$IFOPT} is documented.
That's all there is.
As soon as the rest is implemented, it will be documented as well.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] passing options for the build process.
On 20 March 2012 22:42, peter green wrote: > 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 fpmake on a multiarch arm > system I need to tell it where to find crti.o (it seems freepascal can > successfully build stuff linked against c libraries without finding crti.o > on some architectures but not others). > > For now i've created a symlink at /usr/lib/crti.o to > /usr/lib/arm-linux-gnueabihf/crti.o to make things work but i'd rather not > have to mess with my system in that way. Is there some way of specifying > options so that they actually get passed to ALL compiler invocations in the > build process? I had to fiddle around like this, too, unfortunately. Does the compiler read fpc.cfg when it's building? It may work when adding it there. Reading /etc/ld.so.conf needs to be fixed, too. At the moment the Makefile adds the contents to -Fl, which doesn't work when there are wildcards. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] passing options for the build process.
In our previous episode, peter green said: > 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 fpmake on a multiarch > arm system I need to tell it where to find crti.o (it seems freepascal > can successfully build stuff linked against c libraries without finding > crti.o on some architectures but not others). > > For now i've created a symlink at /usr/lib/crti.o to > /usr/lib/arm-linux-gnueabihf/crti.o to make things work but i'd rather > not have to mess with my system in that way. Is there some way of > specifying options so that they actually get passed to ALL compiler > invocations in the build process? Sounds like a fpmake bug. Please file a bugreport if you haven't done so. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch: Add support for armhf
On 20 Mar 2012, at 23:43, peter green wrote:
I attatch a patch which adds support for armhf to freepascal.
Thanks!
Armhf reffers to arm with the VFP hardfloat variant of EABI. The
defaults are setup to
be suitable for debian armhf (armv7 vfpv3_d16).
Are they Debian-specific? Adding distribution-specific settings to the
compiler is something that should be very much avoided.
Some other remarks:
* please split unrelated parts into separate patches (such as making
the internalerror in ninl.pas unique)
* please create bug reports for those individual patches and attach
them there, it makes them easier to track than on a mailing list
* some stylistic remarks (there may be more, I just quickly glanced
over the patch):
+ if ((target_info.abi=abi_eabi) or (target_info.abi=abi_eabihf))
and
-> change into an in-statement (and as mentioned before, please do not
put multiple if-conditions on the same line except if they are really
short like two boolean variables)
+ if target_info.abi = abi_eabihf then
def_system_macro('FPC_ABI_EABI');
-> Put the then-part on a separate line
+end else begin
-> this should be
end
else
begin
Jonas___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
Then I have minor comments: - in packages/dblib/fpmake.pp at line 23: Author put please instead of "Lacak2" "Ladislav Karrach" (as in dblib.pp header) - in packages/fcl-db/src/sqldb/mssql/makefile.fpc at line 2: change IBConnection to MSSQLConnection ;-) Done. Rev. 20540 and 20541. Now I found also fpmake.pp in packages/fcl-db folder ... There are all sqlDB connectors, may be, that also new TMSSQLConnection should go there ? (I do not understand how these "make" files works ;-) so I only guess) And will you apply also diffs to fcl-db tests ? So we can run complete test suite ... I will do so later today. ;-) -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Wed, Mar 21, 2012 at 3:34 AM, LacaK 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 required field.
>
>
> No Michael, see the example I wrote before.
>
> Create table:
> create table #t (col1 int, col2 varchar(60))
>
> OBS: No column is required.
>
> This INSERT works:
> insert into #t values (1, 'bla bla bla')
>
> This INSERT do NOT works:
> insert into #t (col2) values ('bla bla')
>
>
>
>
> Marcos, can you please test with explicitly allowed nulls:
> create table #t (col1 int NULL, col2 varchar(60) NULL)
>
> (MS SQL Server nullability is controled by database setting "ANSI null
> default" so you can check this setting on your temp database also)
> L.
Yes, of course... you're right.
I have this code that worked before so, I thought something broked.
I had tested before in a different machine with other installation of
MSSQL. My mistake, sorry.
If I find some problems I can post in bugtracker or still early to do this?
--
Michael, sorry for your time.
Marcos Douglas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Wed, Mar 21, 2012 at 5:01 AM, wrote:
>
>
> On Tue, 20 Mar 2012, Marcos Douglas wrote:
>
>> 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)
>> 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 the example I wrote before.
>>>
>>>
>>>
>>> I saw the example :-)
>>>
>>>
Create table:
create table #t (col1 int, col2 varchar(60))
OBS: No column is required.
This INSERT works:
insert into #t values (1, 'bla bla bla')
This INSERT do NOT works:
insert into #t (col2) values ('bla bla')
>>>
>>>
>>>
>>> This kind of SQL is passed as-is to MSSQL. To my knowledge, SQLDB does
>>> not
>>> change it.
>>>
>>> If you had been using parameters, it would have been a different story.
>>
>>
>> Does matter if I use or not parameters.
>
>
> Yes, of course. In that case, SQLDB does some preprocessing of your SQL
> statement.
>
> This can easily be checked. Try setting ParamCheck to 'False' before
> executing your statement.
I don't have such problem because I have my own SQLdb wrapper and
params works a bit different.
Anyway, thanks (and sorry) for your time for help me.
Best regards,
Marcos Douglas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
On Wed, 21 Mar 2012, Marcos Douglas wrote: On Wed, Mar 21, 2012 at 3:34 AM, LacaK wrote: create table #t (col1 int NULL, col2 varchar(60) NULL) (MS SQL Server nullability is controled by database setting "ANSI null default" so you can check this setting on your temp database also) L. Yes, of course... you're right. I have this code that worked before so, I thought something broked. I had tested before in a different machine with other installation of MSSQL. My mistake, sorry. If I find some problems I can post in bugtracker or still early to do this? -- Michael, sorry for your time. No problem. I'm glad the problem turned out not to be in FPC, and that it is now solved anyway. It means there is lots of useful expertise on these mailinglists :) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
Yes, of course... you're right. ;-)) If I find some problems I can post in bugtracker or still early to do this? IMO, You can post them also here. Once Michael commits changes to fcl-db test suite I will run complete test suite and if any problems appears I will resolve them ASAP. (Although I do not expect any bugs, because I already ran these tests) L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch: Add support for armhf
Jonas Maebe wrote: On 20 Mar 2012, at 23:43, peter green wrote: I attatch a patch which adds support for armhf to freepascal. Thanks! Unfortunately just after I sent the mail what I thought was a minor problem in the build system turned out to be more serious than I thought, namely cthreads is crashing at initalisation time. I really need to figure out why before merging this patch is considered. I'll keep you posted on my progress and i'll try and split things up and file bug reports soon. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] passing options for the build process.
On 20 Mar 2012, at 23:42, peter green wrote: > 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 fpmake on a multiarch arm > system I need to tell it where to find crti.o (it seems freepascal can > successfully build stuff linked against c libraries without finding crti.o on > some architectures but not others). The compiler should find the crt*.o files on its own, especially if you create a special compiler binary for the hard float ABI (there is no point in creating a special binary if you still need to separately specify a bunch of additional options to get the correct behaviour). Or are they in distribution-specific directories for the hard float ABI? Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] passing options for the build process.
Jonas Maebe wrote: The compiler should find the crt*.o files on its own, especially if you create a special compiler binary for the hard float ABI (there is no point in creating a special binary if you still need to separately specify a bunch of additional options to get the correct behaviour). Or are they in distribution-specific directories for the hard float ABI? debian/ubuntu are introducing (ubuntu have had support for a while, debian have been a bit slower on the uptake) something called multiarch. The idea of multiarch is that one system will be able to have packages from a mix* of architectures installed at the same time. This is not something specific to armhf (though armhf does of course have a multiarch triplet). As a result of this many libraries (including crt*.o) are now located in /usr/lib/ (or lib/). See debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636802 for previous discussion of this. Debian currently handles this through an entry in the default config file (though the entry they are using right now is likelt to be problematic on a multiarch system with both armel and armhf since it will match the lib directories for both). A key thing about the way multiarch works is that libraries that are packaged to support multiarch will be located in multiarch directories even if the system they are installed on only has packages from one architecture installed. Multiarch is a debian/ubuntu creation. I believe someone is attempting to push support to upstream gcc. I'm not aware of any distros outside the debian family that are currently using it, I am quite happy to prepare a patch that adds the multiarch locations for each architecture to the hardcoded default search paths if you believe that is an appropriate thing to do. * A multiarch triplet represents an ABI. They are based on GNU triplets but not nessacerally identical to them because sometimes one GNU triplet can convert multiple ABIs and sometimes there can be more than one GNU triplet in use for the same ABI. http://wiki.debian.org/Multiarch/Tuples ** in practice most multiatch systems will probally be combinations like i386/amd64 or ppc/ppc64 or maybe armel/armhf but in principle any combination is possible as long as you can find a way (e.g. binfmt-misc with qemu) to make the biniaries run ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
