Does SSAS allow implementation of SCD?

Can I implement a slowly changing dimension type 2 in SSAS. I am looking at creating an SSAS cube which can pull data directly from an operational OLTP database. The source database does not maitain history of changes for the dimensions, and I wanted to know if SSAS will help me keep that history by defining certain dimensions as a SCD. If so how do I define that rule. All tutorials I have read only skim on that topic and don't describe the steps/ways to define it in SSAS. Any help would be appreciated.

While you can use type 2 SCDs (and any other implementation of an SCD) in SSAS, it is not the thing that implements them.

You need to implement them in a Datamart/Datawarehouse and SSAS will then read them from there. What might be of interest to you is the Slowly Changing Dimension task in SSIS. It's not the quickest of components, but it does allow you to use a GUI to define the columns that you want to tracking history on.

Does SQL Server 2005 Express support XQuery Static Type Analysis?

I am quite curious about SQL Server 2005 Express, since I am conducting an XQuery implementation survey for my thesis study.

Yet I still got some questions and may need your help:

1. Does SQL Server 2005 Express support XQuery static type analysis (from http://www.w3.org/TR/xquery-semantics/)?

2. If so, since the W3C standard is still changing, how do you keep up
with the change efficiently?

Your help will be appreciated.
Happy New Year and Thank you,

Selina, Wang

hi Selina,

SQL Server 2005 XQuery implementation is alligned with the July 2004 Working Draft of XQuery http://msdn2.microsoft.com/en-us/library/ms345122.aspx ...

when using a specific tool, you can and obviously should be concerned with the changing stages, but should focus on the actual implementation "as is" for the day by day uses..

regards

Does SQL permit use of a column alias directly in the CASE statement?

Our Case statements can get very long and complicated and I would like to maintain just a single "Case" and than depending on the type of set I'm processing,
use this generic "Case" statement to properly decode the value. My SQL code is listed below.

Select
'PCAR' as [vtyp]
,Case
When [vtyp]='PCAR' and substring(veh_vin,8,1)= 'A' Then 'Cyl = V-6 Fuel = Gasoline'
When [vtyp]='PTRK' and substring(veh_vin,8,1)= 'A' Then 'Cyl = V-8 Fuel = Diesel'
When [vtyp]='PCAR' and substring(veh_vin,8,1)= 'B' Then 'Cyl = V-6 Fuel = CNG'
Else '?' End as 'Engine_Decode'
From veh_owner
Where substring(veh_vin,10,1) = '3' --Selects on cars

Union All

Select
'PTRK' as [vtyp]
,Case
When [vtyp]='PCAR' and substring(veh_vin,8,1)= 'A' Then 'Cyl = V-6 Fuel = Gasoline'
When [vtyp]='PTRK' and substring(veh_vin,8,1)= 'A' Then 'Cyl = V-8 Fuel = Diesel'
When [vtyp]='PCAR' and substring(veh_vin,8,1)= 'B' Then 'Cyl = V-6 Fuel = CNG'
Else '?' End as 'Engine_Decode'
From veh_owner
Where substring(veh_vin,10,1) = '4' --Selects only Trucks

I would like to deploy the SQL code described above but get the following errors:

Msg 207, Level 16, State 1, Line 18 Invalid column name 'vtyp'

Any ideas, comments or help with this issue will be greatly appreciated.

sfmd:

SQL Server does not have this kind of alias. I am not sure that I understand what you are looking for, is this heading in the right direction?:

select veh_vin,
substring ('1 2 PCARPTRK', 4 * convert(integer, substring (veh_vin,10,1)) - 3, 4) as [vtyp],
case when substring (veh_vin,10,1) = '3' and substring (veh_vin,8,1) = 'A' then 'Cyl = V-6 Fuel = Gasoline'
when substring (veh_vin,10,1) = '4' and substring (veh_vin,8,1) = 'A' then 'Cyl = V-8 Fuel = Diesel'
when substring (veh_vin,10,1) = '3' and substring (veh_vin,8,1) = 'B' then 'Cyl = V-6 Fuel = CNG'
else '?'
end as Engine_Decode
from veh_owner
where substring (veh_vin,10,1) between '3' and '4'

-- - Sample Output: -

-- veh_vin vtyp Engine_Decode
-- -- -
-- 1233567A1373 PCAR Cyl = V-6 Fuel = Gasoline
-- 1243567A1373 PCAR Cyl = V-6 Fuel = Gasoline
-- 1253567B1373 PCAR Cyl = V-6 Fuel = CNG
-- 1263567A1373 PCAR Cyl = V-6 Fuel = Gasoline
-- 1334567A1473 PTRK Cyl = V-8 Fuel = Diesel
-- 1344467A1473 PTRK Cyl = V-8 Fuel = Diesel
-- 2344467B1473 PTRK ?

Dave

|||

One thing to consider is persisting these two characters of the VIN. I realize that a VIN is what it is and you cannot change these "smart coded" columns; nonetheless, these portions of the VIN have a specific meaning and it might be a good idea to give these meanings an existence of themselves rather than only existing as a "sub-column".

Dave

|||

>>One thing to consider is persisting these two characters of the VIN. I realize that a VIN is what it is and you cannot change these "smart coded" columns; nonetheless, these portions of the VIN have a specific meaning and it might be a good idea to give these meanings an existence of themselves rather than only existing as a "sub-column".<<

Absolutely. Anytime you find yourself querying on a substring, you probably ought to reconsider what you are doing :)

|||

Perhaps I was not clear enough with my example

My point with this thread is to find a way to use a generic or multi-purpose "Case" Statement to process similar "sets" of rows. The selection of each processing set, in this case either all cars or all trucks, but never a mixed group of vehicles can be handled a thousand different ways by configuring a "Where" clause.

However the vehicle group is selected, I would like to use a generic "Case" for decoding certain values. I will always know the composition of the set (vtyp=value) again either cars or trucks and need to convey/pass this informational profile to the generic "Case" statement.

Notice that a car "A" in VIN position 10 decodes differently than a truck "A" in VIN position 10, that's the crux of the problem. Sure it's easy to use and maintain 2 different "Case" Statements(1 for car and 1 for trucks), but that's not what I initially would prefer to do. It's sure to get out of hand very quickly.

I hope this helps clarify my issue

|||In answer to your question "no" you cannot do what you want without making it dynamic SQL.|||

How about having UDF on this..

Create Function dbo.VehData(@.Vtype as varchar(10), @.VinId Varchar(10))
returns Table As
Return (Select
@.Vtype as [vtyp]
,Case
When @.Vtype='PCAR' and substring(veh_vin,8,1)= 'A' Then 'Cyl = V-6 Fuel = Gasoline'
When @.Vtype='PTRK' and substring(veh_vin,8,1)= 'A' Then 'Cyl = V-8 Fuel = Diesel'
When @.Vtype='PCAR' and substring(veh_vin,8,1)= 'B' Then 'Cyl = V-6 Fuel = CNG'
Else '?' End as Engine_Decode
From veh_owner
Where substring(veh_vin,10,1) = @.VinId )

Go

Select * From VehData('PCAR',3)
Union All
Select * From VehData('PTRK',4)
Union ALL
..etc

Does it exist a boolean data type in SQL SERVER ?

Hello. A question please. To define a column of a table in SqlServer, Does it exist a boolean data type ?

Thanks...

Yes, it has a data type for this, this is bit (it is an integer value with the constraint to only allow 0 and 1 (and NULL of course)).

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de

Does Boolean DataType Exists in SQL server

Does boolean data type exists in Sequel if y how? if N y?

How can i opt for boolean ( nearest ) ?

I've used Bit with not null

i want 2 display column of bit datatype into Checkbox .. Is is possible??

Whenver i bind the datatype of bit for checkbox it is throwing an error??

HELP ME HELP MEBit works fine as a boolean field, I don't have any problems. It is most likely a problem with nulls in your data. You can bind the bit filed to the checked property of a checkbox and you can put that checkbox in a repeater or datagrid using TemplateColumn.

Can you show your code. Or have you already resolved this issue. I know it is a bit old.

Does bit data type function as boolean?

Hi,

I have some applications working fine with Sql Server 7 and Jet 4.
I'm doing some tests with Sql Server 2000 to port these applications to it. I'm having some troubles to query tables using a bit field. For example:

These query worked fine in Sql Server 7:

"Select <fields> from <table> where <boolean/bit field>"

Now I have to do this way:

"Select <fields> from <table> where <bit field> = 1"

Why does this happen? Sql Server 2000 doesn't recognize a boolean value anymore? It's easier and more comprehensive (to me) to use the first way.

Does anyone know why this is happening? Does Sql Server work different than older versions?

Thanks!

Fabianohttp://dbforums.com/arch/43/2002/4/343538

Originally posted by fabiano
Hi,

I have some applications working fine with Sql Server 7 and Jet 4.
I'm doing some tests with Sql Server 2000 to port these applications to it. I'm having some troubles to query tables using a bit field. For example:

These query worked fine in Sql Server 7:

"Select <fields> from <table> where <boolean/bit field>"

Now I have to do this way:

"Select <fields> from <table> where <bit field> = 1"

Why does this happen? Sql Server 2000 doesn't recognize a boolean value anymore? It's easier and more comprehensive (to me) to use the first way.

Does anyone know why this is happening? Does Sql Server work different than older versions?

Thanks!

Fabiano|||nice thread, sbaru

especially joe celko's advice not to use BIT

did you notice that no one actually answered the question "...so the correct, non-proprietary datatype for representing a boolean value is...?"

fabiano, your question "Sql Server 2000 doesn't recognize a boolean value anymore?" is not quite accurate -- i don't think it ever did

if you can change the datatype, you might consider a numeric field like TINYINT or INTEGER instead of BIT

see also Booleans in SQL Server (http://searchdatabase.techtarget.com/ateQuestionNResponse/0,289625,sid13_cid556536_tax285649,00.html)

rudy|||Thanks Rudy and Sbaru,

I've been advised to use tinyint (or some integer variant) to do it. I have some doubts about use tinyint instead of bit to represent a boolean type as follows:

1. Didn't bit type created to represent boolean values? Why does it exist? It what kind of situation am I going to use it?

2. Is bit an optimized type to work with?

3. I know it doesn't make sense to summarize or group by a bit field but it's very common to use this type of field to count records in a table or query by it.

Ex:
Employees that have dependents:

"Select Cod_emp from Employees Where Dep_emp"

Count the number of these employees:

"Select Count(Cod_emp) from Employees Where Dep_emp"

These queries above are common in some situations.

Note that I don't need to explicit "Dep_emp = 1" Or "Dep_emp = 0", it's just "Dep_emp". The query is clearer to read.

I have many queries this way. If I change the bit types to tinyint will they work fine or I will have to change the structure of all my queries?

Thanks for your time!

Fabiano|||1) no, BIT was created to store bits

2) depends what you mean by "optimized"

3) "Note that I don't need to explicit "Dep_emp = 1" Or "Dep_emp = 0", it's just "Dep_emp". The query is clearer to read."

whether it is clearer to read is a matter of opinion

"Dep_emp" by itself means nothing to me

"Dep_emp = 1" means nothing to me either

if the purpose of the Dep_emp column is to indicate whether the employee belongs to the department, then i suggest that it is not at all clear, and in fact is poor design

but yes, you are going to have to change the structure of all your queries

rudy|||It doesn't work that way..

USE Northwind
GO

CREATE TABLE myTable99 (col1 bit)
GO

INSERT INTO myTable99(Col1) SELECT 1 UNION ALL SELECT 0
GO

--Doesn't work
SELECT * FROM myTable99 WHERE Col1 TRUE
--Works
SELECT * FROM myTable99 WHERE Col1 = 1
GO

DROP TABLE myTable99
GO

And what is dep_emp...it must be predefined somewhere..

Also it sounds like all of your SQL code is in the app...now would be a good time to turn them in to stored procedures|||I understood. I'm going to change some queries in my applications.

I've already have most of my queries in stored procedures and views, and these queries use boolean fields in criteria search the way I've described.

Returning to those doubts I've mentioned:

1) Yes. Bit fields were created to store bits. But bit value seems to use in boolean cases. When do I need to store pure bits? If the type was byte instead of bit it would make sense, but bit? Bit value accepts only 0 or 1, True or False, Yes or No or some variance of it. That's why I've thought in use it to store this type of value. But it's ok! I've understood that it won't work this way.

2) When I've mentioned "optimized" I wanted to know if Sql Server treat this type of field in a different way. Do you know if it proceeds?

3) The field "Dep_emp" was not the better example. Think in a gender field to store "male" or "female" where "true" could be "female" and so on. In this case a query like "Select Name_cus from Customers Where Gen_cus" would return just the females ones in a case of a promotion for the female customers for example. In this case, untill now, I didn't have to explicit "Where Gen_cus = 1". I've been used just "Where Gen_cus" that it seems to be clearer once you think in "boolean way".

My doubt is why did MS change the way of treatment of bit fields in Sql Server 2000? Any other DBMS or older versions of Sql Server recognizes the ANSI-SQL "Where <boolean field>" without the need of explicit the true or false value. Once it's a boolean field it doesn't make sense to explicit the value, right? It's true or false, nothing more. I thought this type of field was created to treat these situations in a "optimized" way, even just to clear the queries.

This way of treatment of boolean values helps us even more than this. In a table that stores the quantity of dependents of a employee (like children, parents, ...) you will be able to query for employees that have dependents just using the boolean way, for example:

"Select Cod_emp from Employess Where Dependents_emp"

Or

"Select Cod_emp from Employees Where Not Dependents_emp"

Note that I don't need to explicit "Where Dependents_emp > 0" or "Where Dependents_emp = 0". I don't need, in this case, to know how many dependents each employee has, just to know who they are. There're many reasons for this kind of query. This way of query worked not just in bit fields but in all numeric fields. Any value different than 0 was treated as true.

The biggest problem is that I'll need to separate my apps in 2 versions. One for any DBMS and one just for Sql Server 2000. I'm not worried about the performance using a "native" Sql of each DBMS. I'm worried about the portability of my apps to any DBMS, that's why I often use ANSI-SQL, even because the performance boost is not too sensitive.

Thanks again!

Fabiano|||i could be wrong, but i don't think sql server has ever supported boolean

it goes against everything we've come to expect from microsoft, that they would have a standard feature in an early database and then stop supporting it -- that just doesn't make sense

as far as your rather creative way of using an integer such as number of dependents in a WHERE clause as a boolean...

"Any value different than 0 was treated as true" ?

that may be the way it works in mysql, but it certainly is not standard behaviour, as far as i know, and all i can say is, i hope i never have to support one of your apps, because that is certainly counter-intuitive

at least, to me ;)|||Hi Rudy,

Please forgive me if it seemed that I've been rude or arrogant. Believe, I was not intended to. My english is very poor and I don't know how to expressing my words very well. I've been just "translating" my "portuguese thoughts" in "english words" and I suppose you got me wrong.

It seems to me that you got angry about anything I've said in your words:

"...whether it is clearer to read is a matter of opinion
Dep_emp by itself means nothing to me
Dep_emp = 1 means nothing to me either..."

That's not possible that you couldn't see the mean of these codes. It's very clear. You don't need to know the total structure of the project to suppose that it's a query that brings rows where "Dep_emp" is "true". Just it!

--

"...and in fact is poor design."

How can you say something like that without the knowledge enough about the project?

--

"i could be wrong, but i don't think sql server has ever supported boolean..."

Yes. You're wrong. The bit field was treated as boolean untill Sql Server 7. My apps stopped to work only when I upgraded to Sql Sever 2000.

--

"as far as your rather creative way of using an integer such as number of dependents in a WHERE clause as a boolean..."

The more experience more creativity, indeed.

--

"Any value different than 0 was treated as true ?
that may be the way it works in mysql, but it certainly is not standard behaviour, as far as i know..."

I think you don't have a basic knowledge about another RDBMS than Sql Server 2000. This behavior has been standard at least in Jet, Sql Server (untill 7), MySql and Postgre SQL. I'm working with all these ones and I can say that they work fine.

--

"...i hope i never have to support one of your apps, because that is certainly counter-intuitive."

Yes. You're totally right. My apps need more "creativity" and I think you've not got it enough.

--

Please take a good look at the links below (they're all from Microsoft as you can see):

http://support.microsoft.com/default.aspx?scid=kb;en-us;129803
"0=False, non-zero=True"

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html/vadatBoolean.asp
"When numeric data types are converted to Boolean values, 0 becomes False and all other values become True."

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/acdata/ac_8_con_03_7uzy.asp
"Converting to bit promotes any nonzero value to 1."

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_ba-bz_2it0.asp
"Microsoft SQL Server optimizes the storage used for bit columns."

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/oledbsql/9_ole_13_7s6r.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/oledbsql/9_ole_13_10ha.asp
*Sqloledb mapps bit data type to boolean data type according to the table shown.

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/maintain/trans/ch20.asp
"Efficient datatypes

...Narrow columns make narrow tables, and narrow tables allow you to store more rows on a single data page...

...If your table contains a series of flags with Yes/No or False/True type of information, the best datatype for such columns is BIT. This type is especially effective when you have several columns of type BIT in a table..."

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbls7/html/vblrfvbspec10_2a.asp
"...A zero numeric value converts to the literal False. All other numeric values convert to the literal True."

--

You can see that I've followed the MS' suggestions. That's why my disappointment with the change of treatment of the bit type.

I'm not saying Sql Server is a bad RDBMS. I use it for a long time and I like its performance and stability. I often suggest it for my customers. Then you don't need to get personally offended. It was not intension. Sorry Rudy.

Fabiano
IT Solution Engineer|||fabiano, i was not angry, and i am not angry now

i've been working with databases since the mid '70s, and i do have plenty of experience with them

what is "creative" to you may not seem so to someone else

you are entitled to your opinion, and i am entitled to mine, which i have arrived at after working with many different databases for many decades

i have plenty of creativity, my friend

good luck to you sir

rudy

p.s. you say sql server 7 "treated" BIT as BOOLEAN, but that's not the same thing as supporting BOOLEAN|||Come on Rudy, admit it! Everything you know you learned by scanning the back cover of "Databases For Dummies" at Barne's And Noble!

It's time to face the music!

:p|||sheeeeeesh

flame wars...

Why are people soooooooo sensitive...

Is it the ability to lash out in anonymity ?

And fabiano...chill

Please forgive me if it seemed that I've been rude or arrogant. Believe, I was not intended to. My english is very poor and I don't know how to expressing my words very well. I've been just "translating" my "portuguese thoughts" in "english words" and I suppose you got me wrong.

That translating part I find goes both ways...with the expression, and the interpretation...

Take everything with a grain of salt...nobody at the sites (well with the exception of a few) are not here, not to help...

Now back to the thing...

Where is your code stored? In an Access front end? VB? Stored procedures?

And Can you post the DDL and or code so we can have a look?

Maybe only a Blindman (get the pun) can interpret something we haven't seen.

I'm very curious as to what you have there (It's the only way we learn too)

Thanks|||How I was asking for help (I know nobody here is obligated to, it's just a forum) and it seemed Rudy didn't like my insistence in some points. I was testing nobody, just debating to see if I could do something not to need changing my whole code.

I have some codes in sp, views, using the execute method of ado in vb and some dlls in mts. The job will be enormous considering all projects and tecnologies involved with.

I think I don't need to post any part of the code. The doubt is simple. Once it doesn't matter if I'm querying from a sp, an execute method or view, Sql Server will be always the "interpreter". If the query was "Select <something> from <some table> Where <some field>", it would be interpreted the same way, independently the method used.

I know "treat by" and "supporting" are different things, but the mean of it is the same. If I can have a condition search like "Where <bField>" and the RDBMS returns the records means that it treated the content of that field as boolean, even the RDBMS doesn't support boolean types (and that's it what have been done by earlier versions of Sql Server).

I don't have all of that experience because I began to work with projects design at the mid' 80s (10 years latter). Even so I think the time is not the only manner to measure the ability of a professional. There're plenty of professionals that don't worry about their evolution.

But it's ok. I've interpreted wrong all of those words I'm sure. Forgive me.

About the anonymity I think there's something wrong. Fabiano is my true name. Brasil, Gois, Goinia is my true physical location. If the problem is a telephone number here it goes: +55 (62) 259-7567 (Commercial. I'll be there from January, 5). I don't speak english very well (as you can see) but if we have patience I guess we can understand each other.

Fabiano
Entitled to my opinion: IT Solution Engineer|||fabiano, your english is fine, that was never the problem, in fact, your english is way better than my portuguese

;)

i understand your frustration, and all i can say is, you have learned a valuable lesson about creativity versus flexibility and maintainability

i practice what i call "defensive sql" and WHERE BITFIELD by itself is not very defensive, as you have found out

good luck with your upgrade

rudy|||Rudy,

You don't need to know portuguese once I came for help in a foreign forum (for me ;)). It's my obligation to know how to express my doubts, I know.

With the improvement of my english I can see clearly now. It was not your (or Brett's) fault, sorry. It was seemed to me that you've been ironic in your answers, but was not.

I respect your knowledge. Unfortunatelly the earlier versions of Sql Server did work the way I told, but it's not the problem. That sintax I've demonstrated is ANSI-SQL and not a "native" one.

I've been using ANSI-SQL thinking the same way of yours "defensive sql". To have not problems at all (unless the performance was critical, although it would be the last thing I was change).

I think that I'll need to call for mommy... :)

Fabiano|||I like Rudy's concept of "defensive SQL". Its certainly possible to be so creative in a search for the elegant solution that it becomes difficult for even experience SQL programmers to decipher your logic later on. What I refuse to do, though, is to dumb down my code so that it is readable by any VB developer that comes along. Efficiency and functionality are still of higher importance.

At least thats what I read in "SQL For Idiots".

blindman :cool:|||Fabiano,

Where's Goias?

Getting ready for New Years eve?

And is that really an ANSI Compliant SQL?

Anyone got a link to them?

Still dusting off my 6.5 book to take a look see...|||Originally posted by fabiano
That sintax I've demonstrated is ANSI-SQL and not a "native" one.i don't know if your syntax actually was ANSI

i think ANSI syntax requires you to say WHERE BOOLFIELD IS TRUE or WHERE BOOLFIELD IS FALSE

you left off the IS TRUE part ;)

(i could be wrong -- i don't have an intimate knowledge of the ANSI standard, and the Mimer SQL Validator (http://developer.mimer.se/validator/index.htm) appears to be down at the moment)

in any case, i do not see the value in using ANSI sql intended for one data type (BOOLEAN) on a different datatype (BIT)

i.e. WHERE BITFIELD IS TRUE wouldn't have worked with sql server 7 BIT fields anyway, right?

rudy|||Hey...pretty exotic...

http://www.brazil.travelmall.com/travelmall/region/Brasillia+and+Goias

Got any 6 month consulting gigs opening up?

Sounds like you'll need a hand or two...|||Hmmm. This is from that link:

Here are some points that will make your trip more pleasant:
1) Take good care in your personal hygiene and dress to avoid ridicule and to fit in with the locals.

Never been to good with that "dress to avoid ridicule" thing... ;-)|||I liked this one

Generally be wary of what you do to avoid offending or causing trouble.|||Hmm. They must have a big sign out front that says "No Americans allowed".|||HEY!

I resemble that remark!|||http://docs.zf.jcu.cz/sql1992.txt

"8.12 <search condition>
...
Format

<boolean test> ::= <boolean primary> [ IS [ NOT ] <truth value> ] "

* it seems to be optional to specify the truth value.

"...

Leveling Rules
1) The following restrictions apply for Intermediate SQL:
a) A <boolean test> shall not specify a <truth value>."

* here's a recommendation.

"...
24)Subclause 8.12, "<search condition>":
a) A <boolean test> shall not specify a <truth value>."

* that's the recommendation again.

"...
12.4 Calls to a <procedure>
...
TYPE;
type BIT is array (NATURAL range <>) of BOOLEAN;"

* here's saying that each bit is a boolean value.

----

This doc reproduces the entire content of ANSI-SQL-92 Standard.
How my english is not at all good, I've transported a part of the doc above to be interpreted.

What it seems to be clear is that BIT and BOOLEAN are synonymous.
This way Sql Server 7 seems to be ANSI-SQL-92 Compliant and Sql Server 2000 is not. I say that because Sql Server 7 works fine with my code, no problems.

For example. If you have a table like this:

Cus_id as Integer, Cus_Name as Varchar(50), Cus_gen as Bit

*Cus_gen: (0) male, (1) female

With some records like these:

1, Rudy, 0
2, Fabiano, 0
3, MCrowley (Ozzy Osbourne), 0
4, Brett Kaiser, 0
5, Suzy, 1

You can query females this way (Sql Server 7):

Select Cus_name Where Cus_gen

But using Sql Server 2000 you'll need to do this way:

Select Cus_name Where Cus_gen = 1

Once the value of "Cus_gen" is a boolean (or bit) you don't need to specify the boolean value, it doesn't make sense, it's true or false, nothing more.

For example, in VB (or any language) to do a loop through the records of a table you do something like that:

<open your recordset>

While Not adoRS.Eof

<do something>
adoRS.MoveNext

Wend

I do not need to specify:

While Not adoRS.Eof = True
or
While adoRS.Eof = False

Or a condition to verify whether a number is odd or even:

If X Mod 2 then
<even>
Else
<odd>
End If

I don't need to do:

If X Mod 2 <> 0 then

And so on. I've been used thus. This way we save a processor time taking out the need of the comparison "<> 0" or "=True" and, at the same time, you let your app smaller.

I don't remeber where I've read about these tips. I'll look for it later. I remember just something about "how you optimize your code" or something like that. I guess was at MS.com, don't remember.

In many cases the bandwidth of 100 Mbits of a huge LAN is not enough to provide a good performance, than we have to use the creativity to improve it. Worse when you working on an eCommerce. I use the standards to develop but I try to maintain my apps the minimun code as possible.

I'm not trying to explain my point of view. I'm trying to know if the way I work is actually a good way or if there's better ways to do it.

Thanks!

Fabiano|||congratulations on digging up the 1992 standard

again, all i can say is, too bad you have to rewrite all your code

want to know how i design male/female columns?

instead of

... Where Cus_gen

i prefer

... Where Cus_gen = 'F'

but that's just me, eh

rudy|||My e-mail is: fabianomaiafranco@.hotmail.com (it's my messenger passport too).

Thanks!!!

Fabiano
The Pretentious ;)

Does ASP 3.0 Support Varchar(Max) Data Type

Does ASP 3.0 support Varchar(Max) Data Type?

I am having problems displaying asp 3 recordset with varchar(max) data type...

ADO.NET 2.0 supports varchar(max) field. Older versions will support it as well since SQL will send back as text to older clients.

Does ALTER COLUMN effect the data?

I just want to change the length of 2 fields. They're CHAR and NVARCHAR type. I want to change the length from 50 to 75.

Will doing this effect the data? Will it delete the data in those columns? I just want to make sure before I do anything. The table contains about 2.5 million rows, so I don't want to mess anything up. I'm aware that the script may take a while to run and finish, but I'm only concerned about data integrity.

Here is my example script syntax to show what I'm planning to do:

Code Snippet

alter table credit alter column writeoffreason char(75) not null;

Does it matter what type of data is in the columns? For now, it's only CHAR and NVARCHAR.

I also read somewhere that you can increase length but cannot decrease without repercussions?

Thanks!

It will not delete, but SS has to allocate space in order to accomodate the CHAR one, because it has to pad with spaces to the right. This statement will not only affect metadata, it will affect actual space allocation. Check table fragmentation after it has finished.

AMB

|||thanks for the confirmation, i had thought so that the data integrity would remain intact.

Does 2008 will offer a "between lookup"?

Hi,

does SSIS 2008 will finally offer a "between lookup"?

the current lookup support only the equal (=) operator, but when we play with Type 2 SCD dimensions, its important to also test the dates using a between.

or better, the operator used in the comparison should be an option instead of a equal only.

Thanks.

You can already do such lookup in SSIS 2005 using Partial or None cache Lookup mode.

Neither SSIS 2005, nor SSIS 2008 support such lookups in Full cache mode.

|||

but its a row by row process and everytime the system execute the query against the lookup database.

with million of rows and more to load , this is not efficient.

at least, do you plan to improve the lookup component?

|||

Willgart1 wrote:

but its a row by row process and everytime the system execute the query against the lookup database.

with million of rows and more to load , this is not efficient.

at least, do you plan to improve the lookup component?

Hi Willgart1,

There has been no announcement of changes to the lookup functionality in SSIS2008. Announcements on new functionality are not being made until Microsoft can be absolutely sure that that new functionality will make it - in other words they are announcing stuff after they've built it rather than before. Hence, because there has been no announcement doesn't mean there won't be anything. I'm keeping my fingers crossed on improvements to LOOKUP.

-Jamie

|||

Alberto Ferrari wrote a Range Lookup component that we presented at an italian conference last month (www.sqlconference.it).

In the next days we should finish a little documentation of the component and we will publish it on www.sqlbi.eu

It works in memory and is pretty flexible in the way you can configure the match expression.

Just a few days... if you subscribe to the newsletter on www.sqlbi.eu you'll receive an update when it'll be available, otherwise you can check our blogs (http://www.sqljunkies.com/weblog/aferrari/ and http://sqlblog.com/blogs/marco_russo/).

Marco Russo

http://www.sqlbi.eu

http://sqlblog.com/blogs/marco_russo

Does "text type" belong to SQL2 standard ?

Hi,

I am developping an application that should work with different RDBMS.

I need to store a field of 500 characters.

Hence, I thought of using the type "text" that works with MySQL, but I am wondering if it is part of SQL standard or if it is supported by the main RBDMS (Orcale, DB2, SQL Server ...).

Thanks in advance,

SylvainThe "Text" datatype is not part of the ANSI SQL99 standard. Most vendors also have their own variants of datatypes. The nearest agreements in datatypes for your purposes I guess would be to use a VARCHAR. However there is still variation, in Oracle this would be a VARCHAR2.

Hope this help you on your way.|||Hi,

Originally posted by gannet
The "Text" datatype is not part of the ANSI SQL99 standard. Most vendors also have their own variants of datatypes. The nearest agreements in datatypes for your purposes I guess would be to use a VARCHAR. However there is still variation, in Oracle this would be a VARCHAR2.


But with MySQL for example VARCHAR is limited to 255. We can't do VARCHAR(500).

So you see any solution ?

Regards
Sylvain|||Unfortunately there will be no vendor independent way araound this, you will need to generate some vendor specific translations. Not what you wanted to hear I know.

Documentation

I'd like to know what best practice is on documenting a new database that I
created. What type of diagrams and definitions and how specific or high
level should the documentation be?
Thanks
that's hard to answer without knowing the particulars of your database
or application, however, i use the following guideline for documenting
pretty much anything i work on: if someone new were to take over your
role, would they have enough documentation to do the job?
sorry for the unspecific answer.
arthur

Documentation

I'd like to know what best practice is on documenting a new database that I
created. What type of diagrams and definitions and how specific or high
level should the documentation be?
Thanksthat's hard to answer without knowing the particulars of your database
or application, however, i use the following guideline for documenting
pretty much anything i work on: if someone new were to take over your
role, would they have enough documentation to do the job?
sorry for the unspecific answer.
arthur

Documentation

I'd like to know what best practice is on documenting a new database that I
created. What type of diagrams and definitions and how specific or high
level should the documentation be?
Thanksthat's hard to answer without knowing the particulars of your database
or application, however, i use the following guideline for documenting
pretty much anything i work on: if someone new were to take over your
role, would they have enough documentation to do the job?
sorry for the unspecific answer.
arthur

Document Storage inside DB?

Has anyone got any experience or opinions about the
pros/cons of storing Office Type Documents inside an
image field in the database as opposed to storing a URL
pointer to the file in the filesystem?
Assuming there will be several GB of documents Im
thinking it would be better to keep these out of the
database.
AdamA common approach is to :-
Store the documents on a file server
Store a pointer to the Documents in the DB (to aid searching)
HTH
Ryan Waight, MCDBA, MCSE
"Adam" <atoth@.msdnspam.com> wrote in message
news:07ab01c3b4d3$2e07d430$a501280a@.phx.gbl...
> Has anyone got any experience or opinions about the
> pros/cons of storing Office Type Documents inside an
> image field in the database as opposed to storing a URL
> pointer to the file in the filesystem?
> Assuming there will be several GB of documents Im
> thinking it would be better to keep these out of the
> database.
> Adam
>|||Hi,
We are providing content management software that's using such an approach -
but we are using both DB and FileSystem as a storage for the documents. For
storing the documents inside the database, we use a "document-breaker" to
split the documents in meaningfull parts (e.g. the html documents are split
in tags and text).
The advantages we have with the documents inside the database:
- one single resource that contains the whole system
- easy backup
- depending on the document splitting, we can track and validate cross
document references
The advantages we have by also storing the documents in the file system:
- fast document access (knowing the ID, we don't need a query to the DB)
- fast search capability (using Windows Index Services)
By the way: we have productive systems using this approach with 2000+
documents.
Sven
"Adam" <atoth@.msdnspam.com> wrote in message
news:07ab01c3b4d3$2e07d430$a501280a@.phx.gbl...
> Has anyone got any experience or opinions about the
> pros/cons of storing Office Type Documents inside an
> image field in the database as opposed to storing a URL
> pointer to the file in the filesystem?
> Assuming there will be several GB of documents Im
> thinking it would be better to keep these out of the
> database.
> Adam
>|||I see two approaches that use a "file system" is this the
Windows "file system" that you are referring to and if
so... how do you insure the documents are not deleted?
>--Original Message--
>Has anyone got any experience or opinions about the
>pros/cons of storing Office Type Documents inside an
>image field in the database as opposed to storing a URL
>pointer to the file in the filesystem?
>Assuming there will be several GB of documents Im
>thinking it would be better to keep these out of the
>database.
>Adam
>.
>|||>--Original Message--
>I see two approaches that use a "file system" is this
the
>Windows "file system" that you are referring to and if
>so... how do you insure the documents are not deleted?
>
Yes - I do mean the Windows File System; in answer to
your question you could disallow Delete rights (assuming
NTFS) - Ive never tried it but the option is there.
Adam|||Thanks for the reply - do you think it would still work
well with say 100,000 documents?
Adam