FreeTDS Development Group

["Thompson, Bill D (London)" <bill_d_thompson AT ml.com>]

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/ 
--------------------------------------------------------