Confusing question or should I address it some where else?

I posted a question here on 12/6/05 about importing data from .csv file and
no one addressed it.
Here is the link
http://www.microsoft.com/technet/co...ogramming&fltr=
And the title is
Subject: import data properly from csv file.
Should I post it some where else or the question was not clear?
Please let me know if there is a better design for this.
I would really appreciate it.
ThanksActually, this is the direct link to your original quiestion:
http://msdn.microsoft.com/newsgroup...86f3&sloc=en-us
I don't really see any need for a global temporary table here. Why can't you
simply query the file directly? You're building stairs in the football field
.
If for some reason you do need a temporary table, create a local one (#name
instead of ##name). Of course local temporary tables are scope-specific, so
you'd have to create it in a top level procedure that starts the whole
process (creates the table, calls a sub procedure to import data, then does
the rest of transformations).
ML
http://milambda.blogspot.com/|||Assuming you know the structure of the resulting table, which would
be likely if you have other code to process it, how about
create table #temptbl (
thisCol thisType,
thatCol thatType
)
insert into #temptbl exec (
'SELECT * into ##temptbl FROM '+
@.linked_server + '...['+@.file + '#' +
@.extension + ']')
-- process as before
drop table #temptbl
If this is all in a procedure, you don't have to explicitly drop
#temptbl, but it's not a bad idea to do so.
Steve Kass
Drew University
sqlster wrote:

>I posted a question here on 12/6/05 about importing data from .csv file and
>no one addressed it.
>Here is the link
>http://www.microsoft.com/technet/co...ogramming&fltr=
>And the title is
>Subject: import data properly from csv file.
>Should I post it some where else or the question was not clear?
>Please let me know if there is a better design for this.
>I would really appreciate it.
>Thanks
>
>|||ML and Steve,
Thank you very much...
"Steve Kass" wrote:

> Assuming you know the structure of the resulting table, which would
> be likely if you have other code to process it, how about
> create table #temptbl (
> thisCol thisType,
> thatCol thatType
> )
> insert into #temptbl exec (
> 'SELECT * into ##temptbl FROM '+
> @.linked_server + '...['+@.file + '#' +
> @.extension + ']')
> -- process as before
> drop table #temptbl
> If this is all in a procedure, you don't have to explicitly drop
> #temptbl, but it's not a bad idea to do so.
> Steve Kass
> Drew University
> sqlster wrote:
>
>

Conflict with logins/usres when Importing databases

Hi,

We have imported several databases from an old SQL Server 2000 deployment in a SQL Server 2005 instance. After the installations we have check that the import doesn't create the logins associated with the users nad now it seems impossible to create "manually" the login. What should be do? Re-import the database after having created the login?

Thanks
You should still be able to create the login using CREATE LOGIN and then run the system proc
sp_change_users_login to map the existing users to the newly created login.

Reimporting the database will probably not work as the SIDs of the new logins will not match those of the old logins.

HTH.
|||Effectively, we have been able to create the login but we are unable to associate it to the user using the the "User Properties". The field "Login" appears empty and disabled, so there is no way to assign a user from this screen.

Reading your answer I understand that I can map the users to the newly created logins using the sp_change_users_login function. It's true? Could you send me a sample of use of this function? How should we execute it? (We are SQL Server newbies coming from Oracle world......)+

Thanks
|||

I assume you imported only your user-database probably using import wizard or something. Security information (users and logins) is stored in 'master' database in SQL Server world. You have to transfer these information from your old database to new one.

Check this out.

How to transfer logins and passwords between instances of SQL Server

http://support.microsoft.com/kb/246133/en-us

|||sample:

sp_change_users_login 'AUTO_FIX', 'some_login'

|||Check the information in Books Online which will give you a full explanation of the options open to you:

http://msdn2.microsoft.com/en-us/library/ms174378.aspx

Essentially to map an existing user Bob to a new login of Bob you're looking at running:

sp_change_users_login 'Update_One', 'Bob', 'Bob';

Hope this helps;