Binary field usage in SQL Server

Can anyone point me in the right direction to find documentation for the problem below?
I need to store and retrieve ten fields of 16-bits each for testing 16 true-false conditions (a total of 160 bits in each record) so I think I'd like to use ten 2-byte binary fields (160 "bit" fields would be quite unmanageble, if even possible [I think there is some kind of limit to the number of fields in a single record]).
I'm not quickly finding in the SQL Server's online documentation how to test for, use and update binary fields. I'll keep looking, but can anyone point me in the right direction? I'm using VB, if that makes any difference.

The post below is from SQL Server BOL (books online) documentation on BIT, BINARY and VARBINARY data types. I am assuming you know BIT is proprietry because of three valued logic there is no Boolean data type in ANSI SQL. If you need more information post again. Hope this helps.

bit
Integer data type 1, 0, or NULL.

Remarks
Columns of type bit cannot have indexes on them.

Microsoft? SQL Server? optimizes the storage used for bit columns. If there are 8 or fewer bit columns in a table, the columns are stored as 1 byte. If there are from 9 through 16 bit columns, they are stored as 2 bytes, and so on.

binary and varbinary
Binary data types of either fixed-length (binary) or variable-length (varbinary).

binary [ ( n ) ]

Fixed-length binary data of n bytes. n must be a value from 1 through 8,000. Storage size is n+4 bytes.

varbinary [ ( n ) ]

Variable-length binary data of n bytes. n must be a value from 1 through 8,000. Storage size is the actual length of the data entered + 4 bytes, not n bytes. The data entered can be 0 bytes in length. The SQL-92 synonym for varbinary is binary varying.

Remarks
When n is not specified in a data definition, or variable declaration statement, the default length is 1. When n is not specified with the CAST function, the default length is 30.

Use binary when column data entries are consistent in size.

Use varbinary when column data entries are inconsistent in size.

bigint as unsigned value?

The documentation seems to suggest that I can store either a signed or unsigned value in bigint. If I want to store an unsigned value how do I go about it?

nothing. actually.

just be sure your not going out of range of unsigned bigint.

to ensure that this things

you can however put a constraints on a column

that does not accept negative values

|||

I must still be missing something as the following code fails: with a failure to convert an unsigned int to signed int...

using System;
using System.Collections.Generic;
using System.Text;
using System.Data;
using System.Data.SqlClient;

namespace dbTest
{
class Program
{
static void Main(string[] args)
{
//Create a connection
// Data Source=(local);Database=AdventureWorks;" _
// & "Integrated Security=SSPI;"

string strConnString = @."Data Source=(local);Database=test;Integrated Security=SSPI";
SqlConnection objConn = new SqlConnection(strConnString);
// Create the query

string strSQL = "INSERT INTO dbo.Test (BI) VALUES(@.BI)";
SqlCommand objCmd = new SqlCommand(strSQL, objConn);

// Create parameter
SqlParameter UlongDB;
UInt64 quadValue = 0xFFFFFFFFFFFFFFFF;
UlongDB = new SqlParameter("@.BI", SqlDbType.BigInt);
UlongDB.Value = quadValue;
objCmd.Parameters.Add(UlongDB);

// Insert the record
try
{
objConn.Open();
objCmd.ExecuteNonQuery();
}
catch (Exception e)
{
Console.WriteLine("Exception is: " + e.Message);
}
finally
{
objConn.Close();
}

}
}

Bi-Directional Transactional replication?

Has anyone successfully implemented Bi-Directional Transactional replication?
The documentation on BoL is very limited and there are not too many info
available outside too. We are planning to have active-active SQLServers, that
needs dynamic transactional replication.
I would really appreciate practical advise on BiDirectional Transactional
Replication?
Attention : Paul Ibison and JD . This is the same thread that I created
last month. I couldn't find a way to bump it up so that it becomes active
again. I did also change the subject a little bit, so that it is clear.
I have, it is pretty solid, but is not resilient to schema changes. Also
conflicts can be a pain, so the more you partition your data the easier life
will be for you.
"HowdyDowdy" <HowdyDowdy@.discussions.microsoft.com> wrote in message
news:55B8E404-3560-4016-98E1-68EA35A35F79@.microsoft.com...
> Has anyone successfully implemented Bi-Directional Transactional
> replication?
> The documentation on BoL is very limited and there are not too many info
> available outside too. We are planning to have active-active SQLServers,
> that
> needs dynamic transactional replication.
> I would really appreciate practical advise on BiDirectional Transactional
> Replication?
> Attention : Paul Ibison and JD . This is the same thread that I created
> last month. I couldn't find a way to bump it up so that it becomes active
> again. I did also change the subject a little bit, so that it is clear.
|||HC,
Do you have the Bi-Di trans repl described in detail in your book? Are there
samples in there?
Please let me know.
Thanks,
"Hilary Cotter" wrote:

> I have, it is pretty solid, but is not resilient to schema changes. Also
> conflicts can be a pain, so the more you partition your data the easier life
> will be for you.
>
> "HowdyDowdy" <HowdyDowdy@.discussions.microsoft.com> wrote in message
> news:55B8E404-3560-4016-98E1-68EA35A35F79@.microsoft.com...
>
>
|||Yes, there are. There are some in the update BOL which are pretty good as
well.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"HowdyDowdy" <HowdyDowdy@.discussions.microsoft.com> wrote in message
news:13B145A7-84DF-465F-B486-E780F4C9E9BB@.microsoft.com...
> HC,
> Do you have the Bi-Di trans repl described in detail in your book? Are
there[vbcol=seagreen]
> samples in there?
> Please let me know.
> Thanks,
> "Hilary Cotter" wrote:
life[vbcol=seagreen]
info[vbcol=seagreen]
SQLServers,[vbcol=seagreen]
Transactional[vbcol=seagreen]
created[vbcol=seagreen]
active[vbcol=seagreen]
clear.[vbcol=seagreen]
|||Thanks, Hillary.
I did see the udpated BOL and also an article from www.SqlMag.Com that
talked about BDT replication.
"Hilary Cotter" wrote:

> Yes, there are. There are some in the update BOL which are pretty good as
> well.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> "HowdyDowdy" <HowdyDowdy@.discussions.microsoft.com> wrote in message
> news:13B145A7-84DF-465F-B486-E780F4C9E9BB@.microsoft.com...
> there
> life
> info
> SQLServers,
> Transactional
> created
> active
> clear.
>
>

BiDirectional Replication

Has anyone successfully implemented Bi-Directional Transactional replication?
The documentation on BoL is very limited and there are not too many info
available outside too. We are planning to have active-active SQLServers, that
needs dynamic transactional replication.
I would really appreciate practical advise on BiDirectional Transactional
Repl.
This should help:
http://support.microsoft.com/default...b;en-us;820675
http://msdn.microsoft.com/library/de...lsamp_3ve6.asp
Rgds,
Paul Ibison
|||Paul,
I did already find this info from BoL.
I am looking for someone who has done this already. I spoke to a few DBAs
who haven't heard of this, but they have implemented Transaction Repl before.
"Paul Ibison" wrote:

> This should help:
> http://support.microsoft.com/default...b;en-us;820675
> http://msdn.microsoft.com/library/de...lsamp_3ve6.asp
> Rgds,
> Paul Ibison
>
>
|||This info is not in BOL - there are many setup scripts in the links I
posted. I have implemented it but didn't like the fact that I had to write
my own conflict resolvers and opted for merge instead, despite its overall
slower transfer rate (unless you are updating the same row many times I
would expect this to be generally the case). Also, schema changes will be
more restrictive. Hilary had implemented it in his work, so he can probably
add more if you want to go down this path.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Thanks, Paul. I do appreciate your time.
Hillary, Can you please shed some light on this?
PS : Paul : The updated BoL is available as a download contains the link
that you specified in your first response. I thought of providing this info,
so that people are aware of the availability of the updated BoL.
"Paul Ibison" wrote:

> This info is not in BOL - there are many setup scripts in the links I
> posted. I have implemented it but didn't like the fact that I had to write
> my own conflict resolvers and opted for merge instead, despite its overall
> slower transfer rate (unless you are updating the same row many times I
> would expect this to be generally the case). Also, schema changes will be
> more restrictive. Hilary had implemented it in his work, so he can probably
> add more if you want to go down this path.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
>
|||Well spotted - I'm using the old one at home. Thanks for the correction
Rgds,
Paul Ibison
"HowdyDowdy" <HowdyDowdy@.discussions.microsoft.com> wrote in message
news:A961EFBF-5E13-4178-902B-4C50F8972038@.microsoft.com...
> Thanks, Paul. I do appreciate your time.
> Hillary, Can you please shed some light on this?
> PS : Paul : The updated BoL is available as a download contains the link
> that you specified in your first response. I thought of providing this
info,[vbcol=seagreen]
> so that people are aware of the availability of the updated BoL.
>
> "Paul Ibison" wrote:
write[vbcol=seagreen]
overall[vbcol=seagreen]
be[vbcol=seagreen]
probably[vbcol=seagreen]