Skip to Content.
Sympa Menu

freetds - Re: Many Thanks And a small bug

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Francis Smit <francis AT oztel.com>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Many Thanks And a small bug
  • Date: Sat, 19 Feb 2000 10:54:57 +1100


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?
> >
> >
> >
> > ---
> > You are currently subscribed to freetds as: camber AT ais.org
> > To unsubscribe, forward this message to $subst('Email.Unsub')
> >
> >
>
> ---
> You are currently subscribed to freetds as: francis AT oztel.com
> To unsubscribe, forward this message to $subst('Email.Unsub')

--

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?






Archive powered by MHonArc 2.6.24.

Top of Page