Boolean logic on binary data

Hello,

I have a 21-byte binary field in a SQL Server table with which I want to do boolean AND logic in a report. (Basically, I want to test whether or not individual bits are turned on.) How can I do this? Is it possible to deal with the binary data without first converting it to a string?

Thanks,
MarkYou can analyze your bitmap values using RDL expressions which are regular VB.NET.|||How exactly do I refer to the data, however? What I mean is, I need to access the bits of this big blob of binary data, but SSRS is not binary-friendly--it wants a string or an int.

All I want to do is access 1 particular bit of this binary blob. If I have to convert this to a string somewhere I will, but I'd prefer not to if at all possible.

(FYI, the report needs to analyze the logonHours attribute for an Active Directory user. This is stored as a byte array, with each bit representing 1 hour in a given week--it's 1 if the user can logon, or 0 if he cannot. I'm converting this to be a 21-byte binary field in SQL.)sql

Blobs: File System or DB?

The conventional wisdom on where best to store large binary objects used to
be to store them on the file system because they were slowly processed in
the database. Is this still the case with the latest SQL Server?
We are designing a new system that will store many thousands of TIF files.
We would like to store them in the database because they would then be
coordinated with Backup, Restore, and Transaction issues. How much slower
is the processing of varbinary fields in the db versus the file system?
Thanks,
T"Tina" <TinaMSeaburn@.nospamexcite.com> wrote in message
news:Oy9qbdKSIHA.6060@.TK2MSFTNGP05.phx.gbl...
> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
> Thanks,
> T
>
The following article discusses file system storage vs SQL Server 2005
BLOBs:
ftp://ftp.research.microsoft.com/pub/tr/TR-2006-45.pdf
In SQL Server 2008 there is a new feature called FILESTREAM that directly
addresses the problem. FILESTREAM permits both SQL and file-system access to
binary data while managing the files as if they were part of the database
for backup and transaction control purposes. From my own experience I have
found that FILESTREAM can outperform file-system access for files larger
than about 2MB (YMMV).
http://msdn2.microsoft.com/en-us/library/bb895234(SQL.100).aspx
David Portas|||> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
If you mean SQL Server 2005, then yes; if you mean SQL Server 2008, then
no... as David pointed out, FILESTREAM will address part of this problem
(but I am a little skeptical about performance of backups, concurrency, and
translation layer).

> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
Naturally I would expect a layer of overhead, depending on the number and
size of files you have, in translating the data back and forth between the
database and the application(s).
But, more importantly, and again depending on the number and size of files
you have, I am very sensitive to using expensive disk. I would be very
careful to place the files in a filegroup which is not on a very expensive
SAN (which your database might be using). High performance, fault-tolerant
disk space is very expensive, and it seems a waste to take this space away
from your database to use for, essentially, flat files. If you are using
locally attached storage then this isn't really an issue, but if the file
usage is going to be large, you might consider using a less expensive array
for the files themselves. (You can always keep backups of directory
structures as well, it;'s just very difficult to keep them point-in-time in
sync with the database.) Also keep this in mind if you use a 3rd party for
database hosting; they typically charge a lot more per TB of database
storage, versus flat file storage, so in that case make sure you weigh the
benefits you get from synchronizing your files and data, versus the hit it
takes on your budget.
A

Blobs: File System or DB?

The conventional wisdom on where best to store large binary objects used to
be to store them on the file system because they were slowly processed in
the database. Is this still the case with the latest SQL Server?
We are designing a new system that will store many thousands of TIF files.
We would like to store them in the database because they would then be
coordinated with Backup, Restore, and Transaction issues. How much slower
is the processing of varbinary fields in the db versus the file system?
Thanks,
T
"Tina" <TinaMSeaburn@.nospamexcite.com> wrote in message
news:Oy9qbdKSIHA.6060@.TK2MSFTNGP05.phx.gbl...
> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
> Thanks,
> T
>
The following article discusses file system storage vs SQL Server 2005
BLOBs:
ftp://ftp.research.microsoft.com/pub/tr/TR-2006-45.pdf
In SQL Server 2008 there is a new feature called FILESTREAM that directly
addresses the problem. FILESTREAM permits both SQL and file-system access to
binary data while managing the files as if they were part of the database
for backup and transaction control purposes. From my own experience I have
found that FILESTREAM can outperform file-system access for files larger
than about 2MB (YMMV).
http://msdn2.microsoft.com/en-us/library/bb895234(SQL.100).aspx
David Portas
|||> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
If you mean SQL Server 2005, then yes; if you mean SQL Server 2008, then
no... as David pointed out, FILESTREAM will address part of this problem
(but I am a little skeptical about performance of backups, concurrency, and
translation layer).

> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
Naturally I would expect a layer of overhead, depending on the number and
size of files you have, in translating the data back and forth between the
database and the application(s).
But, more importantly, and again depending on the number and size of files
you have, I am very sensitive to using expensive disk. I would be very
careful to place the files in a filegroup which is not on a very expensive
SAN (which your database might be using). High performance, fault-tolerant
disk space is very expensive, and it seems a waste to take this space away
from your database to use for, essentially, flat files. If you are using
locally attached storage then this isn't really an issue, but if the file
usage is going to be large, you might consider using a less expensive array
for the files themselves. (You can always keep backups of directory
structures as well, it;'s just very difficult to keep them point-in-time in
sync with the database.) Also keep this in mind if you use a 3rd party for
database hosting; they typically charge a lot more per TB of database
storage, versus flat file storage, so in that case make sure you weigh the
benefits you get from synchronizing your files and data, versus the hit it
takes on your budget.
A

Blobs: File System or DB?

The conventional wisdom on where best to store large binary objects used to
be to store them on the file system because they were slowly processed in
the database. Is this still the case with the latest SQL Server?
We are designing a new system that will store many thousands of TIF files.
We would like to store them in the database because they would then be
coordinated with Backup, Restore, and Transaction issues. How much slower
is the processing of varbinary fields in the db versus the file system?
Thanks,
T"Tina" <TinaMSeaburn@.nospamexcite.com> wrote in message
news:Oy9qbdKSIHA.6060@.TK2MSFTNGP05.phx.gbl...
> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
> Thanks,
> T
>
The following article discusses file system storage vs SQL Server 2005
BLOBs:
ftp://ftp.research.microsoft.com/pub/tr/TR-2006-45.pdf
In SQL Server 2008 there is a new feature called FILESTREAM that directly
addresses the problem. FILESTREAM permits both SQL and file-system access to
binary data while managing the files as if they were part of the database
for backup and transaction control purposes. From my own experience I have
found that FILESTREAM can outperform file-system access for files larger
than about 2MB (YMMV).
http://msdn2.microsoft.com/en-us/library/bb895234(SQL.100).aspx
--
David Portas|||> The conventional wisdom on where best to store large binary objects used
> to be to store them on the file system because they were slowly processed
> in the database. Is this still the case with the latest SQL Server?
If you mean SQL Server 2005, then yes; if you mean SQL Server 2008, then
no... as David pointed out, FILESTREAM will address part of this problem
(but I am a little skeptical about performance of backups, concurrency, and
translation layer).
> We are designing a new system that will store many thousands of TIF files.
> We would like to store them in the database because they would then be
> coordinated with Backup, Restore, and Transaction issues. How much slower
> is the processing of varbinary fields in the db versus the file system?
Naturally I would expect a layer of overhead, depending on the number and
size of files you have, in translating the data back and forth between the
database and the application(s).
But, more importantly, and again depending on the number and size of files
you have, I am very sensitive to using expensive disk. I would be very
careful to place the files in a filegroup which is not on a very expensive
SAN (which your database might be using). High performance, fault-tolerant
disk space is very expensive, and it seems a waste to take this space away
from your database to use for, essentially, flat files. If you are using
locally attached storage then this isn't really an issue, but if the file
usage is going to be large, you might consider using a less expensive array
for the files themselves. (You can always keep backups of directory
structures as well, it;'s just very difficult to keep them point-in-time in
sync with the database.) Also keep this in mind if you use a 3rd party for
database hosting; they typically charge a lot more per TB of database
storage, versus flat file storage, so in that case make sure you weigh the
benefits you get from synchronizing your files and data, versus the hit it
takes on your budget.
A

blob data type in SQL Express

Hi all,

I am trying to store binary datafiles into a SQl Express table. However I can not find the BLOB data type when I am designing the table. Are we limited to using that kind of data type in the Express edition? Thanks.

Ke

hi Ke,

if you are searching for a BLOB datatype, you'll miss it..

SQLExpress does support blobs in different formats, binary, varbinary, image and text/ntext as long as the new datatypes as varchar(MAX), nvarchar(MAX), varbinary(MAX), XML

use tempdb;

GO

CREATE TABLE dbo.testBlob (

Id int NOT NULL PRIMARY KEY,

b varchar(max),

i image,

b2 varbinary (50)

);

GO

DROP TABLE dbo.testBlob ;

I've just run SQL Server Management Studio Express, the official graphical client tool for SQLExpress, available for free download at http://www.microsoft.com/downloads/details.aspx?familyid=C243A5AE-4BD1-4E3D-94B8-5A0F62BF7796&displaylang=en, and the relative datatypes are listed in the datatypes combobox when editing tables...

please have a look at http://msdn2.microsoft.com/en-us/library/ms187752.aspx for all supported data types..

regards

BLOB and varying length binary data

I'm not sure about this as I don't have SQL Server handy. My question is if
you have already declared some binary data field say 1500 bytes per record.
Can SQL Server extend the length of the field if I suddenly need more like
3000 bytes for example? So is the field length dynamically adjustable? I
want it to be 1500 bytes long unless 3000 bytes data item has been
found/scanned. I don't want to allocate more as it consumes more disk space.
It goes like half of a G records, so variable length would be desirable..
Any ideas are welcome.
Thanks
Jack
Jacky,
Up to 8,000 bytes you can use the varbinary data type. After that, you can
use image data type (up to 2GB).
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Jacky Luk" <jl@.knight.com> wrote in message
news:uwpMWF4IEHA.2948@.TK2MSFTNGP11.phx.gbl...
> I'm not sure about this as I don't have SQL Server handy. My question is
if
> you have already declared some binary data field say 1500 bytes per
record.
> Can SQL Server extend the length of the field if I suddenly need more like
> 3000 bytes for example? So is the field length dynamically adjustable? I
> want it to be 1500 bytes long unless 3000 bytes data item has been
> found/scanned. I don't want to allocate more as it consumes more disk
space.
> It goes like half of a G records, so variable length would be desirable..
> Any ideas are welcome.
> Thanks
> Jack
>
|||Thank you very much Dejan )
Jacky
"Dejan Sarka" <dejan_please_reply_to_newsgroups.sarka@.avtenta.si > gl
sD:uzutsD6IEHA.3248@.TK2MSFTNGP12.phx.gbl...[vbcol=seagreen]
> Jacky,
> Up to 8,000 bytes you can use the varbinary data type. After that, you can
> use image data type (up to 2GB).
> --
> Dejan Sarka, SQL Server MVP
> Associate Mentor
> Solid Quality Learning
> More than just Training
> www.SolidQualityLearning.com
> "Jacky Luk" <jl@.knight.com> wrote in message
> news:uwpMWF4IEHA.2948@.TK2MSFTNGP11.phx.gbl...
> if
> record.
like[vbcol=seagreen]
> space.
desirable..
>

BitArray to binary

I want to store a binary string in SqlServer from VB .NET through a
stored procedure. I have been storing the binary data in a BitArray
which I am not set on by any means. When I pass the BitArray into a
stored procedure, which is looking for a variable of type binary, it
throws the following: "Object must implement IConvertible." BitArray
obviously does not implement IConvertable.

If anyone has a good way of passing binary data into a stored
procedure through a parameter array I'd appreciate it."Ramzi Abboud" <ramziabb@.gmail.com> wrote in message
news:a5617e65.0410141217.21e48d0@.posting.google.co m...
>I want to store a binary string in SqlServer from VB .NET through a
> stored procedure. I have been storing the binary data in a BitArray
> which I am not set on by any means. When I pass the BitArray into a
> stored procedure, which is looking for a variable of type binary, it
> throws the following: "Object must implement IConvertible." BitArray
> obviously does not implement IConvertable.
> If anyone has a good way of passing binary data into a stored
> procedure through a parameter array I'd appreciate it.

You might get a better answer by posting in a .NET or VB group. I don't know
what a BitArray is, but you can use the ADO Command object to execute stored
procedures with correctly typed parameters, which might be another
possiblity for you.

Simon

Bit to binary problem

I have a field in my database defined as a bit. I need to bind this field to a checkbox I have stored in a datgrid on my webform. I'm having problmes finding the right call in the html

<asp:CheckBox id="chkComplexity" runat="server" Width="125px" Text="Complexity"
WHAT TO PUT HERE !?!?!
</asp:CheckBox

Any help would be greatly appreciatedchkComplexity.Checked = (bool)Reader["CheckBoxField"];|||How wud u do the opposite?? I'm trying to get a bool value into a bit field in one of the fields in my table. Passing in a bool errors out.|||

Try this link it shows you how to get what is in SQL Server before you pass it any value because VB6 boolean evaluates to int. Hope this helps.

http://www.codecomments.com/archive317-2005-2-391341.html