freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- From: Brian Bruns <camber AT umcc.ais.org>
- To: TDS Development Group <freetds AT franklin.oit.unc.edu>
- Subject: Re: Many Thanks And a small bug
- Date: Sat, 19 Feb 2000 08:12:53 -0500 (EST)
Ok, I'll look into setting up some traces into the logging code so you can
run it and see what's going on. I'll give a shout when it is ready.
Brian
On Sat, 19 Feb 2000, Francis Smit wrote:
> Umm in side the actual table designer it defines the field to be
> of type (uniqueidentifier) and its default value is (newid()) the
> result of that function???
>
> Francis Smit wrote:
>
> > Ummm I believe they are defined by MSSQL Server they are
> > put in by it when you use replication, I'll include the following
> > from MSSQL Servers on line books:
> >
> > > Auto-Numbering and Identifier Columns
> > > For each table, a single identifier column can be created that contains
> > > system-generated sequential values that uniquely
> > > identify each row within the table. For example, an identifier column
> > > can generate unique customer receipt numbers for an
> > > application automatically as rows are inserted into the table.
> > > Identifier columns usually contain values unique within the
> > > table on which they are defined. This means that other tables
> > > containing identifier columns can contain the same identity
> > > values used by another table. However, this is usually not a problem
> > > because the identifier values are usually used only within
> > > the context of a single table; the identifier columns do not relate to
> > > other identifier columns in other tables.
> > >
> > > A single globally unique identifier column can be created per table
> > > that contains values unique across all networked computers
> > > in the world. A column that is guaranteed to contain globally unique
> > > values is often useful when similar data from multiple
> > > database systems must be merged (for example, in a customer billing
> > > system with data located in various company subsidiaries
> > > around the world). When the data is merged into the central site for
> > > consolidation and reporting, using globally unique values
> > > prevents customers in different countries from having the same billing
> > > number or customer ID.
> > >
> > > Microsoft? SQL Server? uses globally unique identifier columns for
> > > merge replication to ensure that rows are uniquely
> > > identified across multiple copies of the table.
> > >
> > > SQL Server uses the IDENTITY and ROWGUIDCOL properties to implement
> > > identifier columns.
> > >
> >
> > it can apparently be converted implicitly to the char varchar etc types.
> >
> > Brian Bruns wrote:
> >
> > > If you can give me the exact definition of the user defined type
> > > (ROWGUIDCOL), I'll try it out. I implemented numeric against Sybase but
> > > have never tested them against MS. shrug.
> > >
> > > Cheers,
> > >
> > > Brian
> > >
> > > On Fri, 18 Feb 2000, Francis Smit wrote:
> > >
> > > > Firstly I'd like to thank you all for Helping
> > > > me with getting freeTDS going from our
> > > > Linux/Apache/PHP box to our NT/MS SQL
> > > > Server Boxes, many of you wouldn't know
> > > > you had helped :-)# but I read your emails
> > > > helping others, and solved my own probs,
> > > > esp thanks to those like Brian Bruns and
> > > > and Christian Oyarzun for more personal
> > > > Help Thanks Guys.
> > > >
> > > >
> > > > Now My bug: I've found a sure fire way
> > > > to crash my apache sub process, we have
> > > > DB's for a piece of crapware which I'd
> > > > best not name, that uses many tables
> > > > with ridiculously many fields (most of them,
> > > > are unused when I asked them they said are
> > > > reserved ????huh???), any way at one time
> > > > we played with replication, an as a result we
> > > > have a field called "rowguid" defined like so:
> > > >
> > > > [rowguid] uniqueidentifier ROWGUIDCOL NOT NULL
> > > >
> > > > now if I do a SELECT * FROM tablename on this
> > > > I'll get an error document contained
> > > > no data, and the error log has this line in it,
> > > >
> > > > [Fri Feb 18 11:00:03 2000] [notice] child pid 28520 exit signal
> > > > Segmentation fault (11)
> > > >
> > > > but if I specify the fields I want (and leave) the
> > > > "rowguid" field out all is well, but other smaller
> > > > tables (smaller as in <= 40, 50 ish fields), are fine
> > > > with SELECT *, not a real show stopper, as I rarely
> > > > use SELECT that way, and I certainly don't want
> > > > that many fields at once, but I guess it need fixing,
> > > > if I can help stack tracing what not, just email me.
> > > > Thanks for your time.
> > > >
> > > >
> > > > --
> > > >
> > > > Grisly . oo
> > > > `oO
> > > > Francis Smit
> > > >
> > > >
> > > > Knowledge By Design/OzTel
> > > > Suite 201, 683 George st
> > > > Sydney 2000 NSW
> > > >
> > > > mailto:francis AT kbd.com.au
> > > >
> > > > Tel: +61 2 9212 1399
> > > > Fax: +61 2 9212 5727
> > > > ___________________________________
> > > > m$: How can we stuff you up today?
-
Many Thanks And a small bug,
Francis Smit, 02/17/2000
- <Possible follow-up(s)>
- Re: Many Thanks And a small bug, Bill Doulass, 02/17/2000
- Re: Many Thanks And a small bug, Francis Smit, 02/17/2000
- Re: Many Thanks And a small bug, Geoff Winkless, 02/18/2000
- Re: Many Thanks And a small bug, Brian Bruns, 02/18/2000
- Re: Many Thanks And a small bug, Francis Smit, 02/18/2000
- Re: Many Thanks And a small bug, Francis Smit, 02/18/2000
- Re: Many Thanks And a small bug, Brian Bruns, 02/19/2000
Archive powered by MHonArc 2.6.24.