Showing posts with label group. Show all posts
Showing posts with label group. Show all posts

Tuesday, March 27, 2012

Books OnLine (chm files) Problem

Hi All,

I searched this news group but couldn't find that problem which
is suprising... maybe I'm doing something stupid.

I start one of the chm files (books on line help files).
I read about a topic. There are links.
I click on them. It tells me "Selection is not associated with any
topic. Please try again.". Its ahref link to jscript function:
javascript:hhobj_1.Click() but I do not have it and cannot find it.
So I have to go between all those chm files hoping to find the topic
of my choice.
Plus I want to search them all at once.
There must be a (smart) and easy way to do this.
Please, do you have any suggestions.

Thankfully

Jimmy Ol' BoyJimmy,

> I start one of the chm files (books on line help files). I read about a
> topic. There are links. I click on them. It tells me "Selection is not
> associated with any topic. Please try again.".

A number of the security patches for Internet Explorer that Microsoft
has released this year are known to break the HTML Help ActiveX
control, which is the component that provides the navigation
facilities in help files.

The problem is described in Knowledge Base article 822989 and, in most
cases, installing Critical Update 811630 should sort it out.

822989: http://support.microsoft.com/?kbid=822989
811630: http://support.microsoft.com/?kbid=811630

The exception to this is Windows 2000 with Service Pack 4 installed.
In this case, you must unregister the ActiveX control and then
re-register it, by running the following two commands from a command
prompt:

regsvr32 /u <drive>:\winnt\system32\hhctrl.ocx
regsvr32 <drive>:\winnt\system32\hhctrl.ocx

--
Pete (Microsoft Help MVP)

Sunday, March 11, 2012

Blocking MS Access from linking tables...

Good morning...
I have an Access front end that uses SQL Server linked tables. SQL Server
uses Windows authentication. I have one Windows group that all Access users
are a member of. I added that group to SQL Server logins and gave it
public, datareader, and datawriter rights to the one database that's used.
My front end is locked down, but I want to stop users from creating a new
.mdb and linking SQL Server tables through DSNs or ADO connections or even
just importing the links from the actual front end.. I've tried setting the
"denydatareader" security policy - that keeps the SQL tables from being seen
in the import/link list- but also blocks read rights from the actual front
end database. I could set an Access database password on the front end to
block importing the links, but that only solves one of the three problems
and I want to stay away from Access security altogether.
Is there a way to stop users from creating their own DSNs or connection
objects or linking tables while still using Windows authentication?
Thanks.
Matthew Wells
MWells@.FirstByte.netNo. If you're using Windows authentication, and have granted
users/roles permissions on the base tables, then they can get at the
data no matter what tool they use. An alternative would be to revoke
permissions to public on the tables, and create an Access application
that does not use linked tables, but instead uses pass-through queries
to execute stored procedures. This is a lot more work since you'll
need to create an unbound FE, but it can be done. Only users who are
comfortable working with stored procedures would be able to get at the
data. Another option would be application roles, but they are a really
poor choice for linked table apps. see
http://support.microsoft.com/defaul...;EN-US;Q229564.
--Mary
On Thu, 28 Oct 2004 13:54:05 GMT, "Matthew Wells"
<MWells@.FirstByte.net> wrote:

>Good morning...
>I have an Access front end that uses SQL Server linked tables. SQL Server
>uses Windows authentication. I have one Windows group that all Access user
s
>are a member of. I added that group to SQL Server logins and gave it
>public, datareader, and datawriter rights to the one database that's used.
>My front end is locked down, but I want to stop users from creating a new
>.mdb and linking SQL Server tables through DSNs or ADO connections or even
>just importing the links from the actual front end.. I've tried setting th
e
>"denydatareader" security policy - that keeps the SQL tables from being see
n
>in the import/link list- but also blocks read rights from the actual front
>end database. I could set an Access database password on the front end to
>block importing the links, but that only solves one of the three problems
>and I want to stay away from Access security altogether.
>Is there a way to stop users from creating their own DSNs or connection
>objects or linking tables while still using Windows authentication?
>Thanks.
>Matthew Wells
>MWells@.FirstByte.net
>|||I read that article. It seems to apply only to ADO conenctions. Aren't
linked tables DAO? Does connection pooling work the same way? This is a
database that was converted from Access to SQL Server. We have to lock down
the data from any outside attempts to get it. I don't want to use SQL
authentication because I don't want to maintain two sets of security logins.
I know that using an Access form can create multiple SPIDs on SQL Server
(combo box rowsources et al). What is the downside of using Application
Roles?
Thanks.
Matthew Wells
MWells@.FirstFleet.com
"Mary Chipman" <mchip@.online.microsoft.com> wrote in message
news:vh62o051su3gi6fsaljgvmh1me12b8fu8p@.
4ax.com...
> No. If you're using Windows authentication, and have granted
> users/roles permissions on the base tables, then they can get at the
> data no matter what tool they use. An alternative would be to revoke
> permissions to public on the tables, and create an Access application
> that does not use linked tables, but instead uses pass-through queries
> to execute stored procedures. This is a lot more work since you'll
> need to create an unbound FE, but it can be done. Only users who are
> comfortable working with stored procedures would be able to get at the
> data. Another option would be application roles, but they are a really
> poor choice for linked table apps. see
> http://support.microsoft.com/defaul...;EN-US;Q229564.
> --Mary
> On Thu, 28 Oct 2004 13:54:05 GMT, "Matthew Wells"
> <MWells@.FirstByte.net> wrote:
>
Server[vbcol=seagreen]
users[vbcol=seagreen]
used.[vbcol=seagreen]
even[vbcol=seagreen]
the[vbcol=seagreen]
seen[vbcol=seagreen]
front[vbcol=seagreen]
to[vbcol=seagreen]
>|||Yes, connection pooling works the same way. If you are serious about
locking down the SQL Server database, then DO NOT use Access as a
front-end unless you use it in an unbound scenario as I described
below. You will need to revoke or deny permissions on the tables and
create parameterized stored procedures for all DML operations so that
users can interact with the data only through your stored procedures,
which are executed using a least-priviledged account.
Application roles are intrinsically insecure because you must store
the password that activates them on the client, where it can be
discovered by a determined attacker. If you create an unbound
application that executes under least priviledges, then there likely
won't be much penalty for using them (other than performance) or much
harm if the password is uncovered, but then there's not much benefit,
either. Using Windows authentication is more secure than SQL logins,
and if all users belong to roles that have extremely restricted
permissions that only allow them to execute parameterized stored
procedures, then that's about the best you can do. You can also
provide additional verification and validation in your stored
procedure code (for example, only allowing users to access rows that
they "own").
There is code and discussion of the techniques involved in writing an
unbound Access application in the book described in my sig. It's a lot
of work, but if security is a priority then you have to do it. Access
was designed to be easy to use, not secure.
-- Mary
Microsoft Access Developer's Guide to SQL Server
http://www.amazon.com/exec/obidos/ASIN/0672319446
On Mon, 01 Nov 2004 14:29:21 GMT, "Matthew Wells"
<MWells@.FirstByte.net> wrote:

>I read that article. It seems to apply only to ADO conenctions. Aren't
>linked tables DAO? Does connection pooling work the same way? This is a
>database that was converted from Access to SQL Server. We have to lock dow
n
>the data from any outside attempts to get it. I don't want to use SQL
>authentication because I don't want to maintain two sets of security logins
.
>I know that using an Access form can create multiple SPIDs on SQL Server
>(combo box rowsources et al). What is the downside of using Application
>Roles?
>Thanks.
>Matthew Wells
>MWells@.FirstFleet.com
>"Mary Chipman" <mchip@.online.microsoft.com> wrote in message
> news:vh62o051su3gi6fsaljgvmh1me12b8fu8p@.
4ax.com...
>Server
>users
>used.
>even
>the
>seen
>front
>to
>

Friday, February 24, 2012

BLOB

Hi,
I'm new on the group, sorry if that topic is being repeated.
I'm facing the problem of puting a big object into MS SQL.
Does the procedure is being executed on the DB site, or I can
run it outside the DB (separate e.g. C++ programme).
I've read such articles like 'Who's Afraid of the Big, Bad BLOB?'
and I still don't know how to bite it.
Will be gratefull for any help or Inet sources.
LaurusThe Books Online has some examples. Look for "Building SQL Server
Applications" under the Contents tab.
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
This posting is provided "AS IS" with no warranties, and confers no rights.
"Laurus" <s1336@.poczta.onet.pl> wrote in message
news:dbgu9f$g9m$1@.news.onet.pl...
> Hi,
> I'm new on the group, sorry if that topic is being repeated.
> I'm facing the problem of puting a big object into MS SQL.
> Does the procedure is being executed on the DB site, or I can
> run it outside the DB (separate e.g. C++ programme).
> I've read such articles like 'Who's Afraid of the Big, Bad BLOB?'
> and I still don't know how to bite it.
> Will be gratefull for any help or Inet sources.
> Laurus
>
>|||
> The Books Online has some examples. Look for "Building SQL Server
> Applications" under the Contents tab.
Thanks. I found it.
Laurus

BLOB

Hi,
I'm new on the group, sorry if that topic is being repeated.
I'm facing the problem of puting a big object into MS SQL.
Does the procedure is being executed on the DB site, or I can
run it outside the DB (separate e.g. C++ programme).
I've read such articles like 'Who's Afraid of the Big, Bad BLOB?'
and I still don't know how to bite it.
Will be gratefull for any help or Inet sources.
Laurus
The Books Online has some examples. Look for "Building SQL Server
Applications" under the Contents tab.
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
This posting is provided "AS IS" with no warranties, and confers no rights.
"Laurus" <s1336@.poczta.onet.pl> wrote in message
news:dbgu9f$g9m$1@.news.onet.pl...
> Hi,
> I'm new on the group, sorry if that topic is being repeated.
> I'm facing the problem of puting a big object into MS SQL.
> Does the procedure is being executed on the DB site, or I can
> run it outside the DB (separate e.g. C++ programme).
> I've read such articles like 'Who's Afraid of the Big, Bad BLOB?'
> and I still don't know how to bite it.
> Will be gratefull for any help or Inet sources.
> Laurus
>
>
|||
> The Books Online has some examples. Look for "Building SQL Server
> Applications" under the Contents tab.
Thanks. I found it.
Laurus

BLOB

Hi,
I'm new on the group, sorry if that topic is being repeated.
I'm facing the problem of puting a big object into MS SQL.
Does the procedure is being executed on the DB site, or I can
run it outside the DB (separate e.g. C++ programme).
I've read such articles like 'Who's Afraid of the Big, Bad BLOB?'
and I still don't know how to bite it.
Will be gratefull for any help or Inet sources.
LaurusThe Books Online has some examples. Look for "Building SQL Server
Applications" under the Contents tab.
--
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
This posting is provided "AS IS" with no warranties, and confers no rights.
"Laurus" <s1336@.poczta.onet.pl> wrote in message
news:dbgu9f$g9m$1@.news.onet.pl...
> Hi,
> I'm new on the group, sorry if that topic is being repeated.
> I'm facing the problem of puting a big object into MS SQL.
> Does the procedure is being executed on the DB site, or I can
> run it outside the DB (separate e.g. C++ programme).
> I've read such articles like 'Who's Afraid of the Big, Bad BLOB?'
> and I still don't know how to bite it.
> Will be gratefull for any help or Inet sources.
> Laurus
>
>|||> The Books Online has some examples. Look for "Building SQL Server
> Applications" under the Contents tab.
Thanks. I found it.
--
Laurus

Sunday, February 19, 2012

Blank password works for user account - all other passwords don't!

Hi Group (and thanks for any help given):

I am new to SQL 2005 and have an issue with passwords. I set the password on a user account and tried to access my program (Time Matters.) I received an error message that the application was unable to connect to the system database. When I set the password to blank (no password), the application was able to connect to the SQL db and everything worked just fine.

I've tried several different passwords. Any password besides blank does not work. Blank always does. Obviously I don't want to use a blank password. But where in SQL Server is the setting or could a copy of the original password be "stuck"?

Thanks for your help.

Jeff

Hi,

if you are running on a WIndows 2003 Server you might have the password policy enabled. You can disabled that by navigating to the appropiate user in the Managment Studio and disable the Enforce password policy checkox. YOu can also disable that at server level (not if it is overwritten by a domain policy). Open the group policy snapin for this and navigate to the security option for the password policy.

Which error (number are you getting) ?

HTH, jens Suessmeyer.

http://www.sqlserver2005.de

|||what client application are you using to connect. is it the management studio|||

Thanks for the reply.

It is a Windows 2003 Server and on one of my two users I can turn off the Enforce password policy checkbox (I still cannot connect with any password but a blank one, however.) On the other user, I get the error message 15128 (The CHECK_POLICY and CHECK_EXPIRATION options cannot be turned OFF when MUST_CHANGE is ON.)

Due to security concerns on the server, I cannot turn off the Password Policy enabled setting on the Windows 2003 Server itself.

Any ideas?

Thanks,

Jeff

|||

Yes, I am using the MS SQL Server Management Studio. The application I am trying to connect to its MS SQL Server databases is Time Matters. It creates two different database schemas in SQL Server (one for the "real" database, one for the "training" database.) For each of the databases, it creates a login that is used for workstations to exchange data with SQL Server.

Both logins will only work when the passwords are blank. Both worked earlier, before the server was physically moved (and, I think, some other, security-based changes were made.) It seems like a blank password is equivalent to not having the password checked, but any password entered is verified against some earlier password and deemed as out-of-date, and therefore access is denied.

(By the way, I have set the password(s) back to every password that has ever been used--the only one that works is a blank password.

Thanks for any advice.

Jeff

|||

If "Must Change" is checked, the user has to change the password before they can log in successfully.

If you are enforcing the domain's password policy, any domain password complexity policy (repeated characters, presence of special characters, etc.) must be met as well. Make sure the passwords are sufficiently complex.

Have you tried creating a long, complex password for the login (e.g. "SqlS3rVr{pw") and unchecking the Must Change check box in the login dialog?

Thanks,
Steve

|||

Hello...

I had similar problems. My solution: (i write this while i am actually doing it. the values do work on a standard windows 2003 server, fully updated)
Steps:
create an account: TestMe,
select SQL server authentication, (notice that "enforce", "expiration" and "must change" get enabled.)
Type the password: anypassword (euhm... yep do that twice :-) otherwise...)
deselect: [ ] User must change the password at next logon
close/save the user by clicking OK

open it again (notice that must change is greyed out)
deselect the remaining two options and your done. save and reopen: You can set the password to any you like.

I haven't had no time to test what exactly happens when you turn back on the "enforce password policy" but it would not surprise me if the domain policy is taking over. When using the SQL server authentication it is possible to "bypass" the domain security policy.

Blank password works for user account - all other passwords don't!

Hi Group (and thanks for any help given):

I am new to SQL 2005 and have an issue with passwords. I set the password on a user account and tried to access my program (Time Matters.) I received an error message that the application was unable to connect to the system database. When I set the password to blank (no password), the application was able to connect to the SQL db and everything worked just fine.

I've tried several different passwords. Any password besides blank does not work. Blank always does. Obviously I don't want to use a blank password. But where in SQL Server is the setting or could a copy of the original password be "stuck"?

Thanks for your help.

Jeff

Hi,

if you are running on a WIndows 2003 Server you might have the password policy enabled. You can disabled that by navigating to the appropiate user in the Managment Studio and disable the Enforce password policy checkox. YOu can also disable that at server level (not if it is overwritten by a domain policy). Open the group policy snapin for this and navigate to the security option for the password policy.

Which error (number are you getting) ?

HTH, jens Suessmeyer.

http://www.sqlserver2005.de

|||what client application are you using to connect. is it the management studio|||

Thanks for the reply.

It is a Windows 2003 Server and on one of my two users I can turn off the Enforce password policy checkbox (I still cannot connect with any password but a blank one, however.) On the other user, I get the error message 15128 (The CHECK_POLICY and CHECK_EXPIRATION options cannot be turned OFF when MUST_CHANGE is ON.)

Due to security concerns on the server, I cannot turn off the Password Policy enabled setting on the Windows 2003 Server itself.

Any ideas?

Thanks,

Jeff

|||

Yes, I am using the MS SQL Server Management Studio. The application I am trying to connect to its MS SQL Server databases is Time Matters. It creates two different database schemas in SQL Server (one for the "real" database, one for the "training" database.) For each of the databases, it creates a login that is used for workstations to exchange data with SQL Server.

Both logins will only work when the passwords are blank. Both worked earlier, before the server was physically moved (and, I think, some other, security-based changes were made.) It seems like a blank password is equivalent to not having the password checked, but any password entered is verified against some earlier password and deemed as out-of-date, and therefore access is denied.

(By the way, I have set the password(s) back to every password that has ever been used--the only one that works is a blank password.

Thanks for any advice.

Jeff

|||

If "Must Change" is checked, the user has to change the password before they can log in successfully.

If you are enforcing the domain's password policy, any domain password complexity policy (repeated characters, presence of special characters, etc.) must be met as well. Make sure the passwords are sufficiently complex.

Have you tried creating a long, complex password for the login (e.g. "SqlS3rVr{pw") and unchecking the Must Change check box in the login dialog?

Thanks,
Steve

|||

Hello...

I had similar problems. My solution: (i write this while i am actually doing it. the values do work on a standard windows 2003 server, fully updated)
Steps:
create an account: TestMe,
select SQL server authentication, (notice that "enforce", "expiration" and "must change" get enabled.)
Type the password: anypassword (euhm... yep do that twice :-) otherwise...)
deselect: [ ] User must change the password at next logon
close/save the user by clicking OK

open it again (notice that must change is greyed out)
deselect the remaining two options and your done. save and reopen: You can set the password to any you like.

I haven't had no time to test what exactly happens when you turn back on the "enforce password policy" but it would not surprise me if the domain policy is taking over. When using the SQL server authentication it is possible to "bypass" the domain security policy.

Thursday, February 16, 2012

Blank line in Group using RS2000

I have a table with 3 groups before the detail level. In the second
level I use a filter because one of the group only have information in
the top group. The problem is that when I make a deploy with the
hidden camp - true is show well but when I put false in the Hidden
it's shows a blank line before the other group. How can I solve this
problem?On Apr 2, 9:52 am, pedro.geral...@.netvisao.pt wrote:
> I have a table with 3 groups before the detail level. In the second
> level I use a filter because one of the group only have information in
> the top group. The problem is that when I make a deploy with the
> hidden camp - true is show well but when I put false in the Hidden
> it's shows a blank line before the other group. How can I solve this
> problem?
I'm assuming you already have checked 'Fit table on one page if
possible' as part of the Table control properties. Which may only
shrink the overall table a little bit. Otherwise, as far as I know,
there's not much else that you can do to eliminate the empty row. That
said, you should be able to control this better as part of your stored
procedure or query that is sourcing the report. Hope this helps.
Regards,
Enrique Martinez
Sr. Software Consultant

Friday, February 10, 2012

Bit Value

Hi there, I'm not sure if this the appropriate group so apologies if
it lies outside the boundary.

Senario: I have a customer table with contains a bunch of different
bit values that represent true/false values pertaining to the
customer. I decided for the purpose of clarity I would move these
values into another table. This way I would keep the customer details
(name, age, etc) separate from these values.

Question: Is this a good idea? Or could I somehow tally up all these
bit values and store it in one field in the customer table?

The application is a website and it is built using ASP.NET (VB.NET)

Any opinions would be great.

Cheers,
JackOn 18 Jan 2005 17:06:28 -0800, Jack wrote:

>Hi there, I'm not sure if this the appropriate group so apologies if
>it lies outside the boundary.
>Senario: I have a customer table with contains a bunch of different
>bit values that represent true/false values pertaining to the
>customer. I decided for the purpose of clarity I would move these
>values into another table. This way I would keep the customer details
>(name, age, etc) separate from these values.
>Question: Is this a good idea? Or could I somehow tally up all these
>bit values and store it in one field in the customer table?
>The application is a website and it is built using ASP.NET (VB.NET)
>Any opinions would be great.

Hi Jack,

I'd say: replace the bit columns with somewhat more descriptive columns,
like
ColName CHAR(1) NOT NULL CHECK (ColName IN ('Y', 'N'))

I don't see any advantage in moving these columns to a seperate table,
unless you are approaching the max number of columns per table (quite
unlikely) or unless you need to store these yes/no values only for a
limited subset of your customers.

Best, Hugo
--

(Remove _NO_ and _SPAM_ to get my e-mail address)|||"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:r85su0peh2op7lhf1i7eocfdm2shms59vb@.4ax.com...
> On 18 Jan 2005 17:06:28 -0800, Jack wrote:
>>Hi there, I'm not sure if this the appropriate group so apologies if
>>it lies outside the boundary.
>>
>>Senario: I have a customer table with contains a bunch of different
>>bit values that represent true/false values pertaining to the
>>customer. I decided for the purpose of clarity I would move these
>>values into another table. This way I would keep the customer details
>>(name, age, etc) separate from these values.
>>
>>Question: Is this a good idea? Or could I somehow tally up all these
>>bit values and store it in one field in the customer table?
>>
>>The application is a website and it is built using ASP.NET (VB.NET)
>>
>>Any opinions would be great.
> Hi Jack,
> I'd say: replace the bit columns with somewhat more descriptive columns,
> like
> ColName CHAR(1) NOT NULL CHECK (ColName IN ('Y', 'N'))
> I don't see any advantage in moving these columns to a seperate table,
> unless you are approaching the max number of columns per table (quite
> unlikely) or unless you need to store these yes/no values only for a
> limited subset of your customers.
> Best, Hugo
> --
> (Remove _NO_ and _SPAM_ to get my e-mail address)

Another possible beneficial thing you can do with a 'side-car' table like
this.
Save only one row per distinct combonation of flags and store the integer
key to that bitmap pattern in the main table.
With an indexed column you would be able to more quickly select on those
values.

FamilyType Table
-----
FamilyType Married BothWork HaveKids Descripiotn
--------------------
1 Y Y N DINK
2 Y N Y That Type
3 N Y N Whatever
etc...

customer Table
----

CustomerKey Name FamilyType
----------
1 joe and linda 1
2 bob and rob 3
3 karl and cindy 2

You can use a view, a proc, or an instead of trigger to make sure that
instead of updating the flags, you simply select the correct family type
code.|||Hugo Kornelis (hugo@.pe_NO_rFact.in_SPAM_fo) writes:
> I'd say: replace the bit columns with somewhat more descriptive columns,
> like
> ColName CHAR(1) NOT NULL CHECK (ColName IN ('Y', 'N'))

What can be more descriptive that 0 and 1?

Using character values when there are perfectly usable numeric values
as there are for binary value is asking for trouble. Let's see was
Y/N, T/F, J/N or something else?

We once had a lot of such columns in our database, but almost all are
bit columns these days. And, no, while the name of the type is ab_yesno,
the values are not Y/N, but J/N.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Jack (jack-b@.humlog.com) writes:
> Hi there, I'm not sure if this the appropriate group so apologies if
> it lies outside the boundary.
> Senario: I have a customer table with contains a bunch of different
> bit values that represent true/false values pertaining to the
> customer. I decided for the purpose of clarity I would move these
> values into another table. This way I would keep the customer details
> (name, age, etc) separate from these values.
> Question: Is this a good idea? Or could I somehow tally up all these
> bit values and store it in one field in the customer table?

The last thing would be a bad idea. That's more cumbersome to use, and
more prone to errors.

As for shuffling the bit columns to another table, well, it depends. We
actually did this with our accounts table, since we found that we were
costantly adding bit columns to it, of which some were for tiny marginal
features that were only referred to in one or two places.

Therefore we move these less used bit columns to this table:

CREATE TABLE accountflags (accountno int NOT NULL,
flag varchar(15) NOT NULL,
CONSTRAINT pk_flags PRIMARY KEY (accountno, flag))

That is, the bit column became rows. And a flag is set for an account
if there is a row in the table, else not. The flag themselves are
defined in another table, one that is loaded with data from scripts
when the database is created.

But if all you want to do is move bit columns to a side table, but
keep them as columns, I'm not sure that it's worth the effort.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||machine level things like a BIT or BYTE datatype have no place in a
high level language like SQL. SQL is a high level language; it is
abstract and defined without regard to PHYSICAL implementation. This
basic principle of data modeling is called data abstraction.

SQL is a high level language; it is abstract and defined without regard
to PHYSICAL implementation. This basic principle of data modeling is
called data abstraction.

Bits and Bytes are the <i>lowest<i> units of hardware-specific,
physical implementation you can get. Are you on a high-end or low-end
machine? Does the machine have 8, 16, 32, 64, or 128 bit words? Twos
complement or ones complement math? Hey, the standards allow decimal
machines, so bits do not exist at all! What about NULLs? To be a SQL
datatype, you have to have NULLs, so what is a NULL bit? By definition
a bit, is on or off and has no NULL. If you vendor adds NULLs to bit,
how are the bit-wise operations defined? Oh what a tangled web we
weave when first we mix logical and physical :)

What does the implementation of the host languages do with bits? Did
you know that +1, +0, -0 and -1 are all used for BOOLEANs, but not
consistently? In C#, Boolean values are 0/1 for FALSE/TRUE, while
VB.NET has boolean values of 0/-1 for FALSE/TRUE and they are
proprietary languages from the same vendor. That means <i>all<i> the
host languages -- present, future and not-yet-defined -- can be
different. Surely, no good programmer would ever write non-portable
code by getting to such a low level as bit fiddling!!

There are usually two situations in practice. Either the bits are
individual attributes or they are used as a vector to represent a
single attribute. In the case of a single attribute, the encoding is
limited to two values, which do not port to host languages or other
SQLs, cannot be easily understood by an end user, and which cannot be
expanded.

In the second case what some Newbies, who are still thinking in terms
of second and third generation programming languages or even punch
cards, do is build a vector for a series of "yes/no" status codes,
failing to see the status vector as a single attribute. Did you ever
play the children's game "20 Questions" when you were young?

Imagine you have six components for a loan approval, so you allocate
bits in your second generation model of the world. You have 64 possible
vectors, but only 5 of them are valid (i.e. you cannot be rejected for
bankruptcy and still have good credit). For your data integrity, you
can:

1) Ignore the problem. This is actually what <i>most<i> newbies do.

2) Write elaborate CHECK() constraints with user defined functions or
proprietary bit level library functions that cannot port and that run
like cold glue.

Now we add a 7-th condition to the vector -- which end does it go on?
Why? How did you get it in the right place on all the possible
hardware that it will ever use? Did all the code that references a bit
in a word by its position do it right after the change?

You need to sit down and think about how to design an encoding of the
data that is high level, general enough to expand, abstract and
portable. For example, is that loan approval a hierarchical code?
concatenation code? vector code? etc? Did you provide codes for
unknown, missing and N/A values? It is not easy to design such things!|||--CELKO-- (jcelko212@.earthlink.net) writes:
> machine level things like a BIT or BYTE datatype have no place in a
> high level language like SQL. SQL is a high level language; it is
> abstract and defined without regard to PHYSICAL implementation. This
> basic principle of data modeling is called data abstraction.

Completely wrong. In some language you can say "String" and the language
will allocate for you. In SQL Server you have to specify the max length
of any character column you want to use, and you cannot have more than
8000 bytes on a page. (There is varchar(MAX) in SQL 2005, but practice
will remain to specify an upper bound.)

As a further example, consider the whole range of tinyint, smallint,
int and bigint.

Since you store data on disk, the actual storage format matters a whole
lot to database programmers. Too much storage has bad effect on performance.

And of course, as datatype, BIT has nothing machine-level at all. It is
just a name for something that can have two values. While it could have
been called Boolean, Celko, Pamela or Urban, the name bit is quite good,
because most people have an understanding of how much information you
can cram into a bit.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||> Surely, no good programmer would ever write non-portable
> code by getting to such a low level as bit fiddling!!
There's nothing wrong with fiddling with your bits is there ? :-)

bit mask with 300 flags

Hello,
I have 300 groups. Each user can or can not be associated with certain
group. I would like to represent group membership using corresponding flag
(on/off). Using integer dattatype it will look like : G1- 1, G2 - 2, G3 -
4....
If user is member of group of 1,2 and 3 it will be represented by number 7,
etc.
It is power of 2.With BIGINT data type I can only store up to 63 different
groups. I need to store up to 300 groups.
I could split groups into several integer fields but I was hoping to use
single VARBINARY field.
I am trying to store all flags in VARBINARY(300) field. The problem is
that when populating groups table (see below), SQL server can only perform
bitwise operations when one of the agruments is of integer type. I am trying
to loop through all 300 groups and populate them with power of 2.
I run into the same limitation (no more than 63 groups). Is this possible
to store 300 flags for each groups ina single field?
Thanks,
Igor
CREATE TABLE groups_bin
(
group_id SMALLINT ,
group_name VARCHAR(100),
group_bit_mask VARBINARY(2)
)
DECLARE @.binBitMask VARBINARY(255),@.intID INT,@.intMaxID INT
SELECT @.binBitMask=0x0001,@.intID=1,@.intMaxID=300
WHILE @.intID<=@.intMaxID
BEGIN
INSERT INTO groups_bin(group_id,group_name,group_bit_mask)
VALUES(@.intID,'G'+CAST(@.intID AS VARCHAR(30)),@.binBitMask)
SELECT @.binBitMask=CAST(@.binBitMask*2 AS VARBINARY(255)),@.intID=@.intID+1
PRINT CAST(@.binBitMask*2 AS VARBINARY(255))
ENDYou really should normalize your data. The SQL Engine is optimized for
working with sets of data, not for manual parsing and manipulation of
individual bits in columns.
"Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
news:%23x%23fgOBMFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Hello,
> I have 300 groups. Each user can or can not be associated with certain
> group. I would like to represent group membership using corresponding flag
> (on/off). Using integer dattatype it will look like : G1- 1, G2 - 2, G3 -
> 4....
> If user is member of group of 1,2 and 3 it will be represented by number
> 7,
> etc.
> It is power of 2.With BIGINT data type I can only store up to 63
> different
> groups. I need to store up to 300 groups.
> I could split groups into several integer fields but I was hoping to use
> single VARBINARY field.
> I am trying to store all flags in VARBINARY(300) field. The problem is
> that when populating groups table (see below), SQL server can only perform
> bitwise operations when one of the agruments is of integer type. I am
> trying
> to loop through all 300 groups and populate them with power of 2.
> I run into the same limitation (no more than 63 groups). Is this possible
> to store 300 flags for each groups ina single field?
> Thanks,
> Igor
> CREATE TABLE groups_bin
> (
> group_id SMALLINT ,
> group_name VARCHAR(100),
> group_bit_mask VARBINARY(2)
> )
> DECLARE @.binBitMask VARBINARY(255),@.intID INT,@.intMaxID INT
> SELECT @.binBitMask=0x0001,@.intID=1,@.intMaxID=300
> WHILE @.intID<=@.intMaxID
> BEGIN
> INSERT INTO groups_bin(group_id,group_name,group_bit_mask)
> VALUES(@.intID,'G'+CAST(@.intID AS VARCHAR(30)),@.binBitMask)
> SELECT @.binBitMask=CAST(@.binBitMask*2 AS VARBINARY(255)),@.intID=@.intID+1
> PRINT CAST(@.binBitMask*2 AS VARBINARY(255))
> END
>
>|||"Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
news:%23x%23fgOBMFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Hello,
> I have 300 groups. Each user can or can not be associated with certain
> group. I would like to represent group membership using corresponding flag
> (on/off). Using integer dattatype it will look like : G1- 1, G2 - 2, G3 -
> 4....
> If user is member of group of 1,2 and 3 it will be represented by number
> 7,
> etc.
> It is power of 2.With BIGINT data type I can only store up to 63
> different
> groups. I need to store up to 300 groups.
> I could split groups into several integer fields but I was hoping to use
> single VARBINARY field.
> I am trying to store all flags in VARBINARY(300) field. The problem is
> that when populating groups table (see below), SQL server can only perform
> bitwise operations when one of the agruments is of integer type. I am
> trying
> to loop through all 300 groups and populate them with power of 2.
> I run into the same limitation (no more than 63 groups). Is this possible
> to store 300 flags for each groups ina single field?
>
Is it really appropriate (or necessary) to enshrine the 300 groups in the
metadata?
The more usual model would be
create table Users(id int primary key, name varchar(50) not null)
create table Groups(id int primary key, name varchar(50) not null)
create table UserGroup
(
UserIDint not null references Users on delete cascade,
GroupID id not null references Groups on delete cascade,
constraint pk_UserGroup primary key (UserID,GroupID)
)
create index ix_UserGroup on UserGroup(GroupID)
If you do need to encode the 300 group memberships in a single row, either
because it's appropriate because the 300 groups are as unchanging as the
database schema, or necessary because of some crazy performance requirement,
why not store the 300 memberships in 300 columns?
create table Users
(
id int primary key,
name varchar(50) not null,
InGroup1 bit not null default 0,
InGroup2 bit not null default 0,
. . .
)
David|||Replied in microsoft.public.sqlserver.programming.
Please do not post the same question indepenedently in multiple groups.
--
David Portas
SQL Server MVP
--|||David,
I do not want to have 300 columns because of maintenance reason. Bitmask
approach will allow me to have certain degree of flexibility without need to
change schema (in case I will need to add new groups). For example, I can
create VARBINARY field with extra empty bits to reserve space for future
groups. My main objective is to save space. We will have millions of users.
UserGroup table will be huge if we use traditional relational approach.
Groups are very much static.
Any comments are welcome.
Igor
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:ef%23EjoBMFHA.3184@.TK2MSFTNGP09.phx.gbl...
> "Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
> news:%23x%23fgOBMFHA.3340@.TK2MSFTNGP14.phx.gbl...
>> Hello,
>> I have 300 groups. Each user can or can not be associated with certain
>> group. I would like to represent group membership using corresponding
>> flag
>> (on/off). Using integer dattatype it will look like : G1- 1, G2 - 2, G3 -
>> 4....
>> If user is member of group of 1,2 and 3 it will be represented by number
>> 7,
>> etc.
>> It is power of 2.With BIGINT data type I can only store up to 63
>> different
>> groups. I need to store up to 300 groups.
>> I could split groups into several integer fields but I was hoping to use
>> single VARBINARY field.
>> I am trying to store all flags in VARBINARY(300) field. The problem is
>> that when populating groups table (see below), SQL server can only
>> perform
>> bitwise operations when one of the agruments is of integer type. I am
>> trying
>> to loop through all 300 groups and populate them with power of 2.
>> I run into the same limitation (no more than 63 groups). Is this possible
>> to store 300 flags for each groups ina single field?
> Is it really appropriate (or necessary) to enshrine the 300 groups in the
> metadata?
> The more usual model would be
> create table Users(id int primary key, name varchar(50) not null)
> create table Groups(id int primary key, name varchar(50) not null)
> create table UserGroup
> (
> UserIDint not null references Users on delete cascade,
> GroupID id not null references Groups on delete cascade,
> constraint pk_UserGroup primary key (UserID,GroupID)
> )
> create index ix_UserGroup on UserGroup(GroupID)
>
> If you do need to encode the 300 group memberships in a single row, either
> because it's appropriate because the 300 groups are as unchanging as the
> database schema, or necessary because of some crazy performance
> requirement, why not store the 300 memberships in 300 columns?
> create table Users
> (
> id int primary key,
> name varchar(50) not null,
> InGroup1 bit not null default 0,
> InGroup2 bit not null default 0,
> . . .
> )
> David
>

bit mask with 300 flags

Hello,
I have 300 groups. Each user can or can not be associated with certain
group. I would like to represent group membership using corresponding flag
(on/off). Using integer dattatype it will look like : G1- 1, G2 - 2, G3 -
4....
If user is member of group of 1,2 and 3 it will be represented by number 7,
etc.
It is power of 2.With BIGINT data type I can only store up to 63 different
groups. I need to store up to 300 groups.
I could split groups into several integer fields but I was hoping to use
single VARBINARY field.
I am trying to store all flags in VARBINARY(300) field. The problem is
that when populating groups table (see below), SQL server can only perform
bitwise operations when one of the agruments is of integer type. I am trying
to loop through all 300 groups and populate them with power of 2.
I run into the same limitation (no more than 63 groups). Is this possible
to store 300 flags for each groups ina single field?
Thanks,
Igor
CREATE TABLE groups_bin
(
group_id SMALLINT ,
group_name VARCHAR(100),
group_bit_mask VARBINARY(2)
)
DECLARE @.binBitMask VARBINARY(255),@.intID INT,@.intMaxID INT
SELECT @.binBitMask=0x0001,@.intID=1,@.intMaxID=30
0
WHILE @.intID<=@.intMaxID
BEGIN
INSERT INTO groups_bin(group_id,group_name,group_bit
_mask)
VALUES(@.intID,'G'+CAST(@.intID AS VARCHAR(30)),@.binBitMask)
SELECT @.binBitMask=CAST(@.binBitMask*2 AS VARBINARY(255)),@.intID=@.intID+1
PRINT CAST(@.binBitMask*2 AS VARBINARY(255))
ENDYou really should normalize your data. The SQL Engine is optimized for
working with sets of data, not for manual parsing and manipulation of
individual bits in columns.
"Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
news:%23x%23fgOBMFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Hello,
> I have 300 groups. Each user can or can not be associated with certain
> group. I would like to represent group membership using corresponding flag
> (on/off). Using integer dattatype it will look like : G1- 1, G2 - 2, G3 -
> 4....
> If user is member of group of 1,2 and 3 it will be represented by number
> 7,
> etc.
> It is power of 2.With BIGINT data type I can only store up to 63
> different
> groups. I need to store up to 300 groups.
> I could split groups into several integer fields but I was hoping to use
> single VARBINARY field.
> I am trying to store all flags in VARBINARY(300) field. The problem is
> that when populating groups table (see below), SQL server can only perform
> bitwise operations when one of the agruments is of integer type. I am
> trying
> to loop through all 300 groups and populate them with power of 2.
> I run into the same limitation (no more than 63 groups). Is this possible
> to store 300 flags for each groups ina single field?
> Thanks,
> Igor
> CREATE TABLE groups_bin
> (
> group_id SMALLINT ,
> group_name VARCHAR(100),
> group_bit_mask VARBINARY(2)
> )
> DECLARE @.binBitMask VARBINARY(255),@.intID INT,@.intMaxID INT
> SELECT @.binBitMask=0x0001,@.intID=1,@.intMaxID=30
0
> WHILE @.intID<=@.intMaxID
> BEGIN
> INSERT INTO groups_bin(group_id,group_name,group_bit
_mask)
> VALUES(@.intID,'G'+CAST(@.intID AS VARCHAR(30)),@.binBitMask)
> SELECT @.binBitMask=CAST(@.binBitMask*2 AS VARBINARY(255)),@.intID=@.intID+1
> PRINT CAST(@.binBitMask*2 AS VARBINARY(255))
> END
>
>|||"Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
news:%23x%23fgOBMFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Hello,
> I have 300 groups. Each user can or can not be associated with certain
> group. I would like to represent group membership using corresponding flag
> (on/off). Using integer dattatype it will look like : G1- 1, G2 - 2, G3 -
> 4....
> If user is member of group of 1,2 and 3 it will be represented by number
> 7,
> etc.
> It is power of 2.With BIGINT data type I can only store up to 63
> different
> groups. I need to store up to 300 groups.
> I could split groups into several integer fields but I was hoping to use
> single VARBINARY field.
> I am trying to store all flags in VARBINARY(300) field. The problem is
> that when populating groups table (see below), SQL server can only perform
> bitwise operations when one of the agruments is of integer type. I am
> trying
> to loop through all 300 groups and populate them with power of 2.
> I run into the same limitation (no more than 63 groups). Is this possible
> to store 300 flags for each groups ina single field?
>
Is it really appropriate (or necessary) to enshrine the 300 groups in the
metadata?
The more usual model would be
create table Users(id int primary key, name varchar(50) not null)
create table Groups(id int primary key, name varchar(50) not null)
create table UserGroup
(
UserIDint not null references Users on delete cascade,
GroupID id not null references Groups on delete cascade,
constraint pk_UserGroup primary key (UserID,GroupID)
)
create index ix_UserGroup on UserGroup(GroupID)
If you do need to encode the 300 group memberships in a single row, either
because it's appropriate because the 300 groups are as unchanging as the
database schema, or necessary because of some crazy performance requirement,
why not store the 300 memberships in 300 columns?
create table Users
(
id int primary key,
name varchar(50) not null,
InGroup1 bit not null default 0,
InGroup2 bit not null default 0,
. . .
)
David|||Replied in microsoft.public.sqlserver.programming.
Please do not post the same question indepenedently in multiple groups.
David Portas
SQL Server MVP
--|||David,
I do not want to have 300 columns because of maintenance reason. Bitmask
approach will allow me to have certain degree of flexibility without need to
change schema (in case I will need to add new groups). For example, I can
create VARBINARY field with extra empty bits to reserve space for future
groups. My main objective is to save space. We will have millions of users.
UserGroup table will be huge if we use traditional relational approach.
Groups are very much static.
Any comments are welcome.
Igor
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:ef%23EjoBMFHA.3184@.TK2MSFTNGP09.phx.gbl...
> "Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
> news:%23x%23fgOBMFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Is it really appropriate (or necessary) to enshrine the 300 groups in the
> metadata?
> The more usual model would be
> create table Users(id int primary key, name varchar(50) not null)
> create table Groups(id int primary key, name varchar(50) not null)
> create table UserGroup
> (
> UserIDint not null references Users on delete cascade,
> GroupID id not null references Groups on delete cascade,
> constraint pk_UserGroup primary key (UserID,GroupID)
> )
> create index ix_UserGroup on UserGroup(GroupID)
>
> If you do need to encode the 300 group memberships in a single row, either
> because it's appropriate because the 300 groups are as unchanging as the
> database schema, or necessary because of some crazy performance
> requirement, why not store the 300 memberships in 300 columns?
> create table Users
> (
> id int primary key,
> name varchar(50) not null,
> InGroup1 bit not null default 0,
> InGroup2 bit not null default 0,
> . . .
> )
> David
>

bit mask with 300 flags

Hello,
I have 300 groups. Each user can or can not be associated with certain
group. I would like to represent group membership using corresponding flag
(on/off). Using integer dattatype it will look like : G1- 1, G2 - 2, G3 -
4....
If user is member of group of 1,2 and 3 it will be represented by number 7,
etc.
It is power of 2.With BIGINT data type I can only store up to 63 different
groups. I need to store up to 300 groups.
I could split groups into several integer fields but I was hoping to use
single VARBINARY field.
I am trying to store all flags in VARBINARY(300) field. The problem is
that when populating groups table (see below), SQL server can only perform
bitwise operations when one of the agruments is of integer type. I am trying
to loop through all 300 groups and populate them with power of 2.
I run into the same limitation (no more than 63 groups). Is this possible
to store 300 flags for each groups ina single field?
Thanks,
Igor
CREATE TABLE groups_bin
(
group_id SMALLINT ,
group_name VARCHAR(100),
group_bit_mask VARBINARY(2)
)
DECLARE @.binBitMask VARBINARY(255),@.intID INT,@.intMaxID INT
SELECT @.binBitMask=0x0001,@.intID=1,@.intMaxID=300
WHILE @.intID<=@.intMaxID
BEGIN
INSERT INTO groups_bin(group_id,group_name,group_bit_mask)
VALUES(@.intID,'G'+CAST(@.intID AS VARCHAR(30)),@.binBitMask)
SELECT @.binBitMask=CAST(@.binBitMask*2 AS VARBINARY(255)),@.intID=@.intID+1
PRINT CAST(@.binBitMask*2 AS VARBINARY(255))
END
You really should normalize your data. The SQL Engine is optimized for
working with sets of data, not for manual parsing and manipulation of
individual bits in columns.
"Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
news:%23x%23fgOBMFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Hello,
> I have 300 groups. Each user can or can not be associated with certain
> group. I would like to represent group membership using corresponding flag
> (on/off). Using integer dattatype it will look like : G1- 1, G2 - 2, G3 -
> 4....
> If user is member of group of 1,2 and 3 it will be represented by number
> 7,
> etc.
> It is power of 2.With BIGINT data type I can only store up to 63
> different
> groups. I need to store up to 300 groups.
> I could split groups into several integer fields but I was hoping to use
> single VARBINARY field.
> I am trying to store all flags in VARBINARY(300) field. The problem is
> that when populating groups table (see below), SQL server can only perform
> bitwise operations when one of the agruments is of integer type. I am
> trying
> to loop through all 300 groups and populate them with power of 2.
> I run into the same limitation (no more than 63 groups). Is this possible
> to store 300 flags for each groups ina single field?
> Thanks,
> Igor
> CREATE TABLE groups_bin
> (
> group_id SMALLINT ,
> group_name VARCHAR(100),
> group_bit_mask VARBINARY(2)
> )
> DECLARE @.binBitMask VARBINARY(255),@.intID INT,@.intMaxID INT
> SELECT @.binBitMask=0x0001,@.intID=1,@.intMaxID=300
> WHILE @.intID<=@.intMaxID
> BEGIN
> INSERT INTO groups_bin(group_id,group_name,group_bit_mask)
> VALUES(@.intID,'G'+CAST(@.intID AS VARCHAR(30)),@.binBitMask)
> SELECT @.binBitMask=CAST(@.binBitMask*2 AS VARBINARY(255)),@.intID=@.intID+1
> PRINT CAST(@.binBitMask*2 AS VARBINARY(255))
> END
>
>
|||"Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
news:%23x%23fgOBMFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Hello,
> I have 300 groups. Each user can or can not be associated with certain
> group. I would like to represent group membership using corresponding flag
> (on/off). Using integer dattatype it will look like : G1- 1, G2 - 2, G3 -
> 4....
> If user is member of group of 1,2 and 3 it will be represented by number
> 7,
> etc.
> It is power of 2.With BIGINT data type I can only store up to 63
> different
> groups. I need to store up to 300 groups.
> I could split groups into several integer fields but I was hoping to use
> single VARBINARY field.
> I am trying to store all flags in VARBINARY(300) field. The problem is
> that when populating groups table (see below), SQL server can only perform
> bitwise operations when one of the agruments is of integer type. I am
> trying
> to loop through all 300 groups and populate them with power of 2.
> I run into the same limitation (no more than 63 groups). Is this possible
> to store 300 flags for each groups ina single field?
>
Is it really appropriate (or necessary) to enshrine the 300 groups in the
metadata?
The more usual model would be
create table Users(id int primary key, name varchar(50) not null)
create table Groups(id int primary key, name varchar(50) not null)
create table UserGroup
(
UserIDint not null references Users on delete cascade,
GroupID id not null references Groups on delete cascade,
constraint pk_UserGroup primary key (UserID,GroupID)
)
create index ix_UserGroup on UserGroup(GroupID)
If you do need to encode the 300 group memberships in a single row, either
because it's appropriate because the 300 groups are as unchanging as the
database schema, or necessary because of some crazy performance requirement,
why not store the 300 memberships in 300 columns?
create table Users
(
id int primary key,
name varchar(50) not null,
InGroup1 bit not null default 0,
InGroup2 bit not null default 0,
. . .
)
David
|||Replied in microsoft.public.sqlserver.programming.
Please do not post the same question indepenedently in multiple groups.
David Portas
SQL Server MVP
|||David,
I do not want to have 300 columns because of maintenance reason. Bitmask
approach will allow me to have certain degree of flexibility without need to
change schema (in case I will need to add new groups). For example, I can
create VARBINARY field with extra empty bits to reserve space for future
groups. My main objective is to save space. We will have millions of users.
UserGroup table will be huge if we use traditional relational approach.
Groups are very much static.
Any comments are welcome.
Igor
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:ef%23EjoBMFHA.3184@.TK2MSFTNGP09.phx.gbl...
> "Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
> news:%23x%23fgOBMFHA.3340@.TK2MSFTNGP14.phx.gbl...
> Is it really appropriate (or necessary) to enshrine the 300 groups in the
> metadata?
> The more usual model would be
> create table Users(id int primary key, name varchar(50) not null)
> create table Groups(id int primary key, name varchar(50) not null)
> create table UserGroup
> (
> UserIDint not null references Users on delete cascade,
> GroupID id not null references Groups on delete cascade,
> constraint pk_UserGroup primary key (UserID,GroupID)
> )
> create index ix_UserGroup on UserGroup(GroupID)
>
> If you do need to encode the 300 group memberships in a single row, either
> because it's appropriate because the 300 groups are as unchanging as the
> database schema, or necessary because of some crazy performance
> requirement, why not store the 300 memberships in 300 columns?
> create table Users
> (
> id int primary key,
> name varchar(50) not null,
> InGroup1 bit not null default 0,
> InGroup2 bit not null default 0,
> . . .
> )
> David
>

bit mask

Hello,
I have 300 groups. Each user can or can not be associated with certain
group. I would like to represent group membership using corresponding flag
(on/off). Using integer dattatype it will look like : G1- 1, G2 - 2, G3 -
4....
If user is member of group of 1,2 and 3 it will be represented by number 7,
etc.
It is power of 2.With BIGINT data type I can only store up to 63 different
groups. I need to store up to 300 groups.
I could split groups into several integer fields but I was hoping to use
single VARBINARY field.
I am trying to store all flags in VARBINARY(300) field. The problem is
that when populating groups table (see below), SQL server can only perform
bitwise operations when one of the agruments is of integer type. I am trying
to loop through all 300 groups and populate them with power of 2.
I run into the same limitation (no more than 63 groups). Is this possible
to store 300 flags for each groups ina single field?
Thanks,
Igor
CREATE TABLE groups_bin
(
group_id SMALLINT ,
group_name VARCHAR(100),
group_bit_mask VARBINARY(2)
)
DECLARE @.binBitMask VARBINARY(255),@.intID INT,@.intMaxID INT
SELECT @.binBitMask=0x0001,@.intID=1,@.intMaxID=30
0
WHILE @.intID<=@.intMaxID
BEGIN
INSERT INTO groups_bin(group_id,group_name,group_bit
_mask)
VALUES(@.intID,'G'+CAST(@.intID AS VARCHAR(30)),@.binBitMask)
SELECT @.binBitMask=CAST(@.binBitMask*2 AS VARBINARY(255)),@.intID=@.intID+1
PRINT CAST(@.binBitMask*2 AS VARBINARY(255))
ENDArgh you are seriously, seriously trying to completely denormalize your
data? Have you considered the problem of all the logic involved with
updating a single flag for an individual user in the future? Or even all
the logic involved in just extracting a single flag setting for an
individual user? You've already run into one of the limitations of the
software - the physical limitation of the number of bits a certain field
type can hold. You're relying on what you perceive to be the observed
physical design of the system - nothing says that this won't change down the
road...
This was a very poor design decision...
"Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
news:%23Mmhe%23AMFHA.2384@.tk2msftngp13.phx.gbl...
> Hello,
> I have 300 groups. Each user can or can not be associated with certain
> group. I would like to represent group membership using corresponding flag
> (on/off). Using integer dattatype it will look like : G1- 1, G2 - 2, G3 -
> 4....
> If user is member of group of 1,2 and 3 it will be represented by number
> 7, etc.
> It is power of 2.With BIGINT data type I can only store up to 63
> different groups. I need to store up to 300 groups.
> I could split groups into several integer fields but I was hoping to use
> single VARBINARY field.
> I am trying to store all flags in VARBINARY(300) field. The problem is
> that when populating groups table (see below), SQL server can only perform
> bitwise operations when one of the agruments is of integer type. I am
> trying to loop through all 300 groups and populate them with power of 2.
> I run into the same limitation (no more than 63 groups). Is this possible
> to store 300 flags for each groups ina single field?
> Thanks,
> Igor
> CREATE TABLE groups_bin
> (
> group_id SMALLINT ,
> group_name VARCHAR(100),
> group_bit_mask VARBINARY(2)
> )
> DECLARE @.binBitMask VARBINARY(255),@.intID INT,@.intMaxID INT
> SELECT @.binBitMask=0x0001,@.intID=1,@.intMaxID=30
0
> WHILE @.intID<=@.intMaxID
> BEGIN
> INSERT INTO groups_bin(group_id,group_name,group_bit
_mask)
> VALUES(@.intID,'G'+CAST(@.intID AS VARCHAR(30)),@.binBitMask)
> SELECT @.binBitMask=CAST(@.binBitMask*2 AS VARBINARY(255)),@.intID=@.intID+1
> PRINT CAST(@.binBitMask*2 AS VARBINARY(255))
> END
>|||Sorry, but you have a lousy design and the best thing you can do is get rid
of it. The standard way to represent a many-to-many relationship is called a
Junction Table or Joining Table. Something like this:
CREATE TABLE UserGroups (user_id INTEGER REFERENCES Users (user_id),
group_id INTEGER REFERENCES Groups (group_id), PRIMARY KEY (user_id,
group_id))
I recommend you study a book on data modelling if you aren't already
familiar with relational design principles.
David Portas
SQL Server MVP
--|||A design change would be best, however if you insist on doing something like
this you can take a look at SQL Server's own sprocs for handling roles and
users.
Check out the code in sp_addrole, sp_addrolemember etc. In the SQL Server
version it uses a varbinary(2048) field to store up to 16k of options.
HTH
Rick Sawtell
MCT, MCSD, MCDBA|||No problem, David. The criticism is greately appreciated :) I am
familiar with relational design principals. The reason why I opted for
bitmask approach is because I am trying to save space. Every user can be
member of any/all of 300 groups (number of groups fixed). We can save a lot
of space if we can represent user's group membership with a single, for
example VARBINARY field. With traditional relational approach space
consumption would be higher.
We will have millions of users and I was hoping bimask approach will save
us a lot of space.
Please let me know if my thinking is incorrect.
Thanks,
Igor
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:zbidnU2EcNHB8t_fRVn-ow@.giganews.com...
> Sorry, but you have a lousy design and the best thing you can do is get
> rid of it. The standard way to represent a many-to-many relationship is
> called a Junction Table or Joining Table. Something like this:
> CREATE TABLE UserGroups (user_id INTEGER REFERENCES Users (user_id),
> group_id INTEGER REFERENCES Groups (group_id), PRIMARY KEY (user_id,
> group_id))
> I recommend you study a book on data modelling if you aren't already
> familiar with relational design principles.
> --
> David Portas
> SQL Server MVP
> --
>|||Rick, I am not 'insisting' on this design. My goal is to save space. We
will have millions of users. Number of groups is predefined and fixed. I see
no difference between representing several flags as Microsoft is doing in
system tables and 300 using bitmask. I think I might be able to save a lot
of space with this design. I can use bitwise logic to set/reset/verify
flags.
Is my thhinking incorrect?
Thanks,
Igor
"Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
news:uIIqJIIMFHA.1300@.TK2MSFTNGP10.phx.gbl...
>A design change would be best, however if you insist on doing something
>like
> this you can take a look at SQL Server's own sprocs for handling roles and
> users.
> Check out the code in sp_addrole, sp_addrolemember etc. In the SQL
> Server
> version it uses a varbinary(2048) field to store up to 16k of options.
> HTH
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>|||Michael,
I am trying to conserver space. I have no problems updating flags using
bitwise logic. In fact, I already have prototype working using BIGINT field.
Unfortunately, it only allows me to store 62 flags. I can easily
set/rest/extract users flags.
I was hoping to use VARBINARY to store 300 flags in a single field. We
have predefined/fixed set of groups.
Any comments are welcome.
Thanks,
Igor
"Michael C#" <xyz@.abcdef.com> wrote in message
news:jAp0e.7247$AF3.6586@.fe10.lga...
> Argh you are seriously, seriously trying to completely denormalize your
> data? Have you considered the problem of all the logic involved with
> updating a single flag for an individual user in the future? Or even all
> the logic involved in just extracting a single flag setting for an
> individual user? You've already run into one of the limitations of the
> software - the physical limitation of the number of bits a certain field
> type can hold. You're relying on what you perceive to be the observed
> physical design of the system - nothing says that this won't change down
> the road...
> This was a very poor design decision...
> "Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
> news:%23Mmhe%23AMFHA.2384@.tk2msftngp13.phx.gbl...
>|||Is every user a member of all 300 groups? On average, how many groups would
you say that your users belong to?
"Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
news:eiqaZ6JMFHA.2464@.TK2MSFTNGP10.phx.gbl...
> Michael,
> I am trying to conserver space. I have no problems updating flags using
> bitwise logic. In fact, I already have prototype working using BIGINT
> field. Unfortunately, it only allows me to store 62 flags. I can easily
> set/rest/extract users flags.
> I was hoping to use VARBINARY to store 300 flags in a single field. We
> have predefined/fixed set of groups.
> Any comments are welcome.
> Thanks,
> Igor
>
> "Michael C#" <xyz@.abcdef.com> wrote in message
> news:jAp0e.7247$AF3.6586@.fe10.lga...
>|||P.S. - While you could kludge this design and probably force it to work,
you're trading off maintainability, scalability and speed to save a little
space. Hard drive costs are pretty darn low :)
"Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
news:eiqaZ6JMFHA.2464@.TK2MSFTNGP10.phx.gbl...
> Michael,
> I am trying to conserver space. I have no problems updating flags using
> bitwise logic. In fact, I already have prototype working using BIGINT
> field. Unfortunately, it only allows me to store 62 flags. I can easily
> set/rest/extract users flags.
> I was hoping to use VARBINARY to store 300 flags in a single field. We
> have predefined/fixed set of groups.
> Any comments are welcome.
> Thanks,
> Igor
>
> "Michael C#" <xyz@.abcdef.com> wrote in message
> news:jAp0e.7247$AF3.6586@.fe10.lga...
>|||A couple of notes..
1. Having a join table and storage table is not *that* much bigger storage
wise.
2. Yes, you can use the bitwise logic to set/reset/verify the values
however it is not particularly fast in SQL Server.
On a table with 5 million rows (and a varbinary(2048)) I did an update that
set the bitflag for 100,000 rows or so. It took much more time than doing
an update across the joined tables.
So you might save some space, but you will lose out on speed.
Rick
"Igor Marchenko" <igormarchenko@.hotmail.com> wrote in message
news:O90hw4JMFHA.3080@.TK2MSFTNGP10.phx.gbl...
> Rick, I am not 'insisting' on this design. My goal is to save space. We
> will have millions of users. Number of groups is predefined and fixed. I
see
> no difference between representing several flags as Microsoft is doing in
> system tables and 300 using bitmask. I think I might be able to save a lot
> of space with this design. I can use bitwise logic to set/reset/verify
> flags.
> Is my thhinking incorrect?
> Thanks,
> Igor
>
> "Rick Sawtell" <r_sawtell@.hotmail.com> wrote in message
> news:uIIqJIIMFHA.1300@.TK2MSFTNGP10.phx.gbl...
and
>