Desupport dates

Is the a page online that lists any desupport dates for
the various versions of SQL Server (v7, 2000 etc)http://support.microsoft.com/defaul...en-gb;lifeprods
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Rob" <anonymous@.discussions.microsoft.com> wrote in message
news:b62101c407bb$afa9b4f0$a401280a@.phx.gbl...
> Is the a page online that lists any desupport dates for
> the various versions of SQL Server (v7, 2000 etc)

Designing reusable column transformations?

We receive thousands of files every week from various clients and we attempt to clean the columns using the same technique over and over so the data is consistent. The problem is I dont see a way to reuse complex column transformations in different packages. I would hate to have to go change every package if we change the rules for cleaning a column.

So #1: Can you create some kind of script or .net function that cleans a column and reuse it in multiple packages (or even in the same package)?

#2: Is it possible to call functions from the Derived Column expression builder?

Thanks!

1)May be. You always can use a script component with the transformation rules and copy and paste it many times; it that sounds reasonable to you.

2) No you can not.

|||

Craig, I have had do do the same thign.The best solution is not a script component, as the person above mentioned.

Take the hit, build a custom component. Once you get it built, adding a new column is as simple as adding a new column to the transform.

You will want to build a custom pipline component. Both Wrox and O'riely have some decent chapters decribing how to do this. and there is definately info in microsoft.

I have 350 packages, that all chagne time from european time to us time, in the data flow. By writing 1 component, once, I was able to then delegate the rest of the work, since the hard part was encapsulated in a compoent.

good luck

Design Question - Suggestions Please

We are designing a security model for our application. The security is
for controlling access to various functions(essentially buttons) on
various screens per user group. The problem we are facing is that
different screens support different functions and it is proving hard to
come up with one security table for the whole application. We have two
designs on mind:
1. Security table will have the most common functions (like Save,
Delete etc) as fixed columns and UserDef1, UserDef2 etc for non
standard functions. This is a good model but the system admin will have
problems guessing what UserDef1 means when administering rights.
2. Security table will have all the columns as Function1, Function2
etch (up to a max of say 15 columns) and a seperate table holds the
mapping to say what Function1 means on the screen.
Security
---
Screen | User Group | Function 1 | Function 2 | Function3 ....
Screen Function Map
---
Screen | Function | Name
Ex. 100, Function1, 'Save'
100, Function2, 'Delete' and so on.
This model will enable easy administration and also is extensible.
Please let me know your thoughts on this design.
Thanks for reading the postwill it not be possible to have a table of users, a separate table of
rights, and a table UserRights which links users to what they can do
(perhaps with additional columns for Read, Update, Delete.
Much like you see in the SQL server permissions.|||Hi
I guess you would want something like that
CREATE TABLE Users
(
Userid INT NOT NULL PRIMARY KEY,
Uname VARCHAR(n) NOT NULL
Email...
...
)
CREATE TABLE Functions
(
FunctionId INT NOT NULL PRIMARY KEY,
Ftype VARCHAR(n) NOT NULL...
.....
)
CREATE TABLE Screens
(
ScreenId INT NOT NULL PRIMARY KEY,
Scereen_Descr VARCHAR(n) NOT NULL
......
)
Now ,it is interesting , how to build relationship between those tables . I
don't really know your business requirenments, so based on your narrative
i'd guess
CREATE TABLE Sequrity_System
(
UserID --> Foreign Key to users
FunctionId -->...
ScreenId -->
......
)
Is these combinations of columns unique?If it is make it as Primary Key
"S Chapman" <s_chapman47@.hotmail.co.uk> wrote in message
news:1144065933.043085.21470@.i40g2000cwc.googlegroups.com...
> We are designing a security model for our application. The security is
> for controlling access to various functions(essentially buttons) on
> various screens per user group. The problem we are facing is that
> different screens support different functions and it is proving hard to
> come up with one security table for the whole application. We have two
> designs on mind:
> 1. Security table will have the most common functions (like Save,
> Delete etc) as fixed columns and UserDef1, UserDef2 etc for non
> standard functions. This is a good model but the system admin will have
> problems guessing what UserDef1 means when administering rights.
> 2. Security table will have all the columns as Function1, Function2
> etch (up to a max of say 15 columns) and a seperate table holds the
> mapping to say what Function1 means on the screen.
> Security
> ---
> Screen | User Group | Function 1 | Function 2 | Function3 ....
> Screen Function Map
> ---
> Screen | Function | Name
> Ex. 100, Function1, 'Save'
> 100, Function2, 'Delete' and so on.
> This model will enable easy administration and also is extensible.
> Please let me know your thoughts on this design.
> Thanks for reading the post
>|||Are the function1,2,3,4.. columns in the security table of boolean datatype?
Think of these issues before you freeze on the design:
1.This will not work if your screen has more than 15 functions. So
extensibility might be a problem.
2. Say you have a requirement like you want to add a new function to all the
screens. What would you do about the update. It can't be an update of one
column because each screen will have different functions.
The way I see it, the approach given by Uri Dimant is the best. Though its a
bit too normalized, its seems to be excellent for extensibility.|||Uri Dimant, thanks, your solution seems like the way foward. More
elegant and simple than our earlier design.|||
Yes, I agree with you, Uri's idea is good and we might probaly do
something on similar lines. Just as an aside - we need to add an extra
table to Uri's design called [Screen Functions] that captures the
relation between screens and implemented functions. Without this the
system Admin will be presented with a list of ALL functions (from
Functions table) for a screen even if some or many may not be
appilcable to the screen being administered.