Re: FreeTDS Digest, Vol 119, Issue 3

Frediano Ziglio <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <CAHt6W4dV17H662Qsw3zK9ZDv6-hq+LNCRn_KhxFsQnOa3hxtjQ@mail.gmail.com>
Went into stable (ftp://ftp.freetds.org/pub/freetds/stable/)

2012/12/5 "Tony" Yu Jiang <[email protected]>:
> Hi Frediano,
>
> That patch is almost exactly the same as mine - so I guess mine is
> unnecessary anymore.
>
> I think this patch is perfectly safe to backport to 0.91 since the change
> is so small and so clearly defined. It shouldn't affect anything else.
>
> Thanks!
> Tony
>
>
>
> On Wed, Dec 5, 2012 at 9:00 AM, <[email protected]> wrote:
>
>> Send FreeTDS mailing list submissions to
>>         [email protected]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         http://lists.ibiblio.org/mailman/listinfo/freetds
>> or, via email, send a message with subject or body 'help' to
>>         [email protected]
>>
>> You can reach the person managing the list at
>>         [email protected]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of FreeTDS digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Enable freebcp to specify target database on command line
>>       ("Tony" Yu Jiang)
>>    2. Re: Enable freebcp to specify target database on command  line
>>       (Frediano Ziglio)
>>    3. Re: Memory problems with dbcmd (Frediano Ziglio)
>>    4. Re: Memory problems with dbcmd (Alberto Pulvirenti)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 4 Dec 2012 10:24:27 -0800
>> From: "\"Tony\" Yu Jiang" <[email protected]>
>> Subject: [freetds] Enable freebcp to specify target database on
>>         command line
>> To: [email protected]
>> Message-ID:
>>         <CAD9rgJ=
>> [email protected]>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi there,
>>
>> This patch allows the user to specify a target database on freebcp command
>> line. This is especially useful when accessing SQL Azure, which always
>> returns a connection to a system database.
>>
>> The patch is here:
>>
>> https://github.com/tonyjiang/freetds/commit/4d50f8835f584b042fabe42510f1cede24e5d938
>>
>> It'd be great if you can merge it into freebcp.
>>
>> Cheers,
>> Tony
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 4 Dec 2012 19:27:59 +0000
>> From: Frediano Ziglio <[email protected]>
>> Subject: Re: [freetds] Enable freebcp to specify target database on
>>         command line
>> To: FreeTDS Development Group <[email protected]>
>> Message-ID:
>>         <CAHt6W4fuBAfg=
>> [email protected]>
>> Content-Type: text/plain; charset=UTF-8
>>
>> 2012/12/4 "Tony" Yu Jiang <[email protected]>:
>> > Hi there,
>> >
>> > This patch allows the user to specify a target database on freebcp
>> command
>> > line. This is especially useful when accessing SQL Azure, which always
>> > returns a connection to a system database.
>> >
>> > The patch is here:
>> >
>> https://github.com/tonyjiang/freetds/commit/4d50f8835f584b042fabe42510f1cede24e5d938
>> >
>> > It'd be great if you can merge it into freebcp.
>> >
>> > Cheers,
>> > Tony
>>
>> Thanks for the patch, on official master branch we have a similar patch:
>>
>>
>> http://gitorious.org/freetds/freetds/commit/c34afafd2fec4cbba9b245e4f13a5471c6fb8041
>>
>> Do you think we should backport it on 0.91branch? Usually we do not
>> backport new feature on stable branch but this seems quite safe to me.
>>
>> James fixed the snapshot generation a week ago so snapshots have this
>> patch.
>>
>> Regards,
>>   Frediano
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 4 Dec 2012 19:30:58 +0000
>> From: Frediano Ziglio <[email protected]>
>> Subject: Re: [freetds] Memory problems with dbcmd
>> To: FreeTDS Development Group <[email protected]>
>> Message-ID:
>>         <
>> CAHt6W4fLnOS3AuypN8pRALr1rRsQeHAcNxoyLBNx4quE0dqGNg@mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> 2012/12/4 Alberto Pulvirenti <[email protected]>:
>> > Dear all,
>> >
>> > unfortunately, searching on google seemed to be unsuccessful for this,
>> and
>> > I didn't find any help looking ad previous discussions (maybe since I
>> > subscribed this mailing list).
>> >
>> > I have manage to set up a connection to a MS SQL database server using
>> > freeTDS, but it sometimes (seldom, fortunately) happens that a dbcmd
>> fails.
>> > Looking at the various documentations, it should be a problem of memory
>> > allocation, but this happened even for extremely simple queries like a
>> > "begin transaction", and not always for the same query: it just happened
>> in
>> > a given moment, and it was not either possible to reproduce this problem,
>> > but I remained afraid that it can appear again.
>> > I don't really understand how can dbcmd fail with such a simple query
>> when
>> > the machine is not stuck (which I would think if it is a problem is so
>> > serious that even such a small string cannot be allocated).
>> >
>> > The MS SQL server stays in another machine to which I must connect
>> through
>> > network, although it is a machine internal to the location where all this
>> > stuff runs. Can it happen that a sudden and momentary communication
>> failure
>> > causes dbcmd() to fail? Or its failure are only due to memory allocation
>> > problems?
>> >
>> > Is there any way I can adopt to deeper check this problem?
>> >
>> > Thanks
>> >
>> > Alberto
>>
>> Personally I would exclude a memory problem. If the system fails to
>> allocate few bytes of memory you should note other problems (unless
>> you set some limits on your program for instance using PHP module
>> which limit memory itself).
>>
>> It's possible that connection got broken for some reason (a simple
>> service restart or a backup schedule which put database in some
>> particular state). Or even that server disconnect you cause you where
>> idle for too time (see recent keepalive discussion).
>>
>> Frediano
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 5 Dec 2012 10:38:18 +0100
>> From: Alberto Pulvirenti <[email protected]>
>> Subject: Re: [freetds] Memory problems with dbcmd
>> To: FreeTDS Development Group <[email protected]>
>> Message-ID:
>>         <
>> CAJNp6N3tbXidcTW9iaEM6Lo+wxCLOFTTCHL9n1BsH+7zGx6u+w@mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi,
>>
>> maybe I forgot to clarify a point. The failure I mention refers to the
>> function dbcmd().
>> I checked with a personal MS SQL Server I use for testing and I saw that
>> when the connection is faulty or the DB server is down, what happens is
>> that either the dbsqlsend() fails (and then I catch it) or the dbsqlok()
>> stays pending for a long time.
>> Whenever I try to switch off the server, it stops always there, never at
>> the dbcmd() level.
>>
>> In all the documentations I see, when dbcmd fails it is always explained as
>> a memory problem, and it happens before one tries to send to the server
>> itself. That's what confused me.
>>
>> It is surely possible that in a moment a memory occupancy spike took place
>> which caused this momentary failure (because, maybe I didn't stress this
>> point, but this failure was not a persistent condition, it happened just
>> once or twice and then the communication succeeded).
>>
>> Thanks for any advice.
>>
>> Alberto
>>
>> 2012/12/4 Frediano Ziglio <[email protected]>
>>
>> > 2012/12/4 Alberto Pulvirenti <[email protected]>:
>> > > Dear all,
>> > >
>> > > unfortunately, searching on google seemed to be unsuccessful for this,
>> > and
>> > > I didn't find any help looking ad previous discussions (maybe since I
>> > > subscribed this mailing list).
>> > >
>> > > I have manage to set up a connection to a MS SQL database server using
>> > > freeTDS, but it sometimes (seldom, fortunately) happens that a dbcmd
>> > fails.
>> > > Looking at the various documentations, it should be a problem of memory
>> > > allocation, but this happened even for extremely simple queries like a
>> > > "begin transaction", and not always for the same query: it just
>> happened
>> > in
>> > > a given moment, and it was not either possible to reproduce this
>> problem,
>> > > but I remained afraid that it can appear again.
>> > > I don't really understand how can dbcmd fail with such a simple query
>> > when
>> > > the machine is not stuck (which I would think if it is a problem is so
>> > > serious that even such a small string cannot be allocated).
>> > >
>> > > The MS SQL server stays in another machine to which I must connect
>> > through
>> > > network, although it is a machine internal to the location where all
>> this
>> > > stuff runs. Can it happen that a sudden and momentary communication
>> > failure
>> > > causes dbcmd() to fail? Or its failure are only due to memory
>> allocation
>> > > problems?
>> > >
>> > > Is there any way I can adopt to deeper check this problem?
>> > >
>> > > Thanks
>> > >
>> > > Alberto
>> >
>> > Personally I would exclude a memory problem. If the system fails to
>> > allocate few bytes of memory you should note other problems (unless
>> > you set some limits on your program for instance using PHP module
>> > which limit memory itself).
>> >
>> > It's possible that connection got broken for some reason (a simple
>> > service restart or a backup schedule which put database in some
>> > particular state). Or even that server disconnect you cause you where
>> > idle for too time (see recent keepalive discussion).
>> >
>> > Frediano
>> > _______________________________________________
>> > FreeTDS mailing list
>> > [email protected]
>> > http://lists.ibiblio.org/mailman/listinfo/freetds
>> >
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> FreeTDS mailing list
>> [email protected]
>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>
>>
>> End of FreeTDS Digest, Vol 119, Issue 3
>> ***************************************
>>
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.