Skip to Content.
Sympa Menu

freetds - RE: [freetds] Longstanding issue and 0.64...

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Thompson, Bill D (London)" <bill_d_thompson AT ml.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] Longstanding issue and 0.64...
  • Date: Tue, 30 Nov 2004 16:30:37 -0000

If I have two connections to the database in a program and I want to capture
a TDSDUMP log, I :

export TDSDUMP=stdout

program >mydump.txt

and it works fine. I dont lose anything.

However many programs also write to stdout as well, so I get the program's
normal output interspersed with TDSDUMP log output.
This isn't necessarily a bad thing. It helps sometimes to synchronise whats
happening in freetds with what's happening in the program.

Bill



-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of ZIGLIO, Frediano,
VF-IT
Sent: 30 November 2004 15:43
To: FreeTDS Development Group
Subject: RE: [freetds] Longstanding issue and 0.64...


> From: Lowden, James K
> Sent: lunedì 29 novembre 2004 20.03
>
> > From: ZIGLIO, Frediano, VF-IT
> > Sent: Monday, November 29, 2004 10:16 AM
> >
> > Now that we are more free I would like to discuss some longstanding
> > (big) changes. Mainly logging, thread-safe and row structure!
> >
> > Log:
> > - James open the question many time ago. If would be fine to filter
> > logs by type (network, data and so only) and not only on level
> > - log it's mainly global. Although you can configure log by
> connection
> > a new connection just override all opened logs (not that kind). This
> > make logging global and cause some problems for testing (setting log
> for
> > a connection cause logging for entire server). Also there is a small
> > memory leak allocating name of logging file. This will
> require to put
> > logging file name in TDSSOCKET and an additional TDSSOCKET*
> parameter
> to
> > logging functions
>
> I'd like the log to be opened once, when the library is initialized,
> unless we make the once-per-pid behavior standard.
>
> I think the log format should be standardized; it would be easier to
> grep and scan. I don't see much value in logging the time on every
> line. It's enough that we know when packets were sent and received.
>
> Here's a format suggestion:
>
> LEVEL PID Function (File:Line): text
>
> LEVEL would be one of:
>
> LOGIN
> API
> ASYNC
> DIAG
> ERROR
> PACKET
> LIBTDS
> CONFIG
>

What difference between API and LIBTDS ??

> Continuations of "text" would appear on succeeding lines,
> starting with
> a tab character.
>
> > (perhaps we need also to syncronize access to a single file)
>
> Surely stdio synchronizes writes to a file?
>

stdio ?? If I open 2 connection I need to write to the same file. If I use
same handle I'm sure it write correctly informations but if I open two
handles for the same file probably one write overwrite other write. Well...
I'm not sure but this thing need a bit of testing.

This simple program

#include <stdio.h>
#include <stdlib.h>

int main()
{
FILE *f1, *f2;
f1 = fopen("test.txt","a");
f2 = fopen("test.txt","a");
if (!f1 || !f2) {
fprintf(stderr, "file open error\n");
return 1;
}
fprintf(f1, "test1\n");
fprintf(f2, "test2\n");
fprintf(f1, "test3\n");
fprintf(f2, "test4\n");
fclose(f2);
fclose(f1);
printf("success!\n");
return 0;
}

output

test2
test4
test1
test3

It do not overwrite however sequence it's not correct.

> > - it would be fine to be able to disable compile of
> logging code for
> > embedded systems
>
> Right. If tdsdump() were called in the code via a macro, "TDSDUMP()",
> we could defeat logging with a #define. But are there any embedded
> systems?
>

At present not but some people use FreeTDS in some strange ways...
Also we need a macro to support file:line syntax...

> > Thread-safe:
> > - cancel function can be called from other thread or from signal...
> we
> > have to handle both situations safety...
>
> I don't think FreeTDS should catch signals. It's up to the
> application
> to catch signals and call the API accordingly. If we decide to use
> O_ASYNC, that's another story.
>

I know that it's up the application however dbcancel docs state that a code
inside a signal can call this function (to support alarm or similar) and
SQLCancel docs state that this function can be called from another thread
while connection it's busy.

> > Row structure:
> > - well there is few things to say. It's a shit! We did too
> job to use
> > the same packing method used for getting data and in some
> case we lose
> > IMHO too much memory. All library use to bind parameters
> for input so
> it
> > would be good to use these bindings and compute row on the fly. This
> for
> > rpc/dynamic sql/bcp and if possibly while reading data.
>
> We need to support binary bindings of character data. We lost that
> feature when we implemented iconv throughout.
>

well... this point it's too sum up... There are a bit of issues on this
- all columns data must be packaged before calling libTDS function. This it's
quite complicated and it's one of the reasons of rpc/dynamic sql problems in
dblib/ctlib. ODBC works but I don't like the extra work
- Bill use different code for bulk copy... bulk it's just another type of
insert so I don't see much point in using different code and structures
- Steve Kirkendall too used different code
- in ODBC there is a way to stop receiving/sending a row and restart later
(to accomodate space for large text/binary or similar)

There are many solution/optimization/changes that we can combine to relax
these difficulties. For example thinking about inserting (bulk, rpc, dynamic
call) we call call a libTDS function to start sending data and then call
different functions to insert a parameter/column at a time. Or we can provide
a way to libTDS to grab data directly from binded data (calling for example a
function that convert data for use or similar). Or a mix of the two (libTDS
stop when it don't know who to convert parameters and so higher API can do
the job...).

freddy77
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy, retain or
redistribute it. Click here for important additional terms relating to this
e-mail. http://www.ml.com/email_terms/
--------------------------------------------------------





Archive powered by MHonArc 2.6.24.

Top of Page