Accessing Custom Properties in UI

I am attempting to set my custom properties in the UI I have created for my custom transformation. I can access them in the ProcessInput, but if I try to assign them a new value in my UI the values dont change.

I set the properties up in ProvideComponentProperties

public override void ProvideComponentProperties()

{

// Perform component setup operations

ComponentMetaData.UsesDispositions = false;

// Add Input

IDTSInput90 input = ComponentMetaData.InputCollection.New();

input.Name = "TrimInput";

input.ErrorRowDisposition = DTSRowDisposition.RD_NotUsed;

// Add Output

IDTSOutput90 output = ComponentMetaData.OutputCollection.New();

output.Name = "TrimOutput";

output.SynchronousInputID = input.ID;

IDTSCustomProperty90 Trimproperty = ComponentMetaData.CustomPropertyCollection.New();

Trimproperty.Name = "Trim Values";

Trimproperty.Description = "Selected Trim Values";

IDTSCustomProperty90 Colproperty = ComponentMetaData.CustomPropertyCollection.New();

Colproperty.Name = "Col Names";

Colproperty.Description = "Column Names";

}

btn Click event in UI form

IDTSCustomProperty90 Trimproperty = _dtsComponentMetaData.CustomPropertyCollection["Trim Values"];

Trimproperty.Value = sConcatTrim;

IDTSCustomProperty90 Colproperty = _dtsComponentMetaData.CustomPropertyCollection["Col Names"];

Colproperty.Value = sConcatColNames;

Any suggestions or please point me to any example would be greatly appreciated.

Could you share how you implemented DTSComponentUI interface? It could be that you are not committing changes when you close the UI.

Thanks.

|||

That was the problem .. fixed it. When the ok button was clicked on the form was not setting the form dialog result to ok.

Thank you,

Carlier

Access Violation in SQLSRV32.DLL

I have run into an issue with attempting to process a large result set
returned by SQL Server 2000. This issue disappears when we reduce the amount
of data in the database that is available to the query by deleting records
and reappears when we add the data back. I've been able to narrow down the
cause of the issue to be the driver SQLSVR32.dll by using windows debugging
tools. Even running this query in Query Analyzer causes it to hang.
Actually, the timer at the bottom of the window continues to increment the
time but when you try to cancel or stop the query, it says "Attempting to
cancel". Closing the window will cause Query Analyzer to hang. It does not
do this every time. Sometimes it almost immediately fails and the execution
of the query terminates. The number of records in the table is over 188,000
records. Can anyone shed some light as to what may be going on here? Is
there a limit to the amount of data that SQL Server driver can handle? This
is happening at one of our customer sites and we've been able to reproduce
this in house.
The following is the output from the windows debugger:
The output is from executing the query on the one particular table from
within Query Analyzer.
(720.888): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=000000af ebx=0166c6a0 ecx=ffffe0a8 edx=00002020 esi=01668050 edi=00002020
eip=1f9ddfca esp=0188fafc ebp=0188fb64 iopl=0 nv up ei ng nz na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010283
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINNT\System32\SQLSRV32.dll -
SQLSRV32!SQLSetEnvAttr+76b5:
1f9ddfca 83250000000000 and dword ptr [00000000],0x0 ds:0023:00000000=??
The following is the output from windows debugger after attempting to run
this query through our application
(7d8.888): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=000000af ebx=02007c98 ecx=ffffe0a8 edx=00002020 esi=02008780 edi=00002020
eip=1f9ddfca esp=000e5594 ebp=000e55fc iopl=0 nv up ei ng nz na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010283
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINNT\System32\SQLSRV32.dll -
SQLSRV32!SQLSetEnvAttr+76b5:
1f9ddfca 83250000000000 and dword ptr [00000000],0x0 ds:0023:00000000=??
Any insight into this issue will be greatly appreciated!
Hi Bennie,
Have you already found the solution? I have exactly the same problem. I have
a structure size of 512 bytes and SQLFetchScroll can fetch without AV only
71 rows (set with SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_ARRAY_SIZE, (void *)71,
0)). I have W2K Server with MS SQL Server 2K on server side and W2KPro SP4
on client side; both have MDAC 2.8 and MS SQL SP3a updates, KB815495 and
Q832483 patches applied.
Isaiass
"Bennie" <Bennie@.discussions.microsoft.com> wrote in message
news:2AB71598-C001-4E4E-96C6-38E47CD37577@.microsoft.com...
> I have run into an issue with attempting to process a large result set
> returned by SQL Server 2000. This issue disappears when we reduce the
amount
> of data in the database that is available to the query by deleting records
> and reappears when we add the data back. I've been able to narrow down
the
> cause of the issue to be the driver SQLSVR32.dll by using windows
debugging
> tools. Even running this query in Query Analyzer causes it to hang.
> Actually, the timer at the bottom of the window continues to increment the
> time but when you try to cancel or stop the query, it says "Attempting to
> cancel". Closing the window will cause Query Analyzer to hang. It does
not
> do this every time. Sometimes it almost immediately fails and the
execution
> of the query terminates. The number of records in the table is over
188,000
> records. Can anyone shed some light as to what may be going on here? Is
> there a limit to the amount of data that SQL Server driver can handle?
This
> is happening at one of our customer sites and we've been able to reproduce
> this in house.
> The following is the output from the windows debugger:
> The output is from executing the query on the one particular table from
> within Query Analyzer.
> (720.888): Access violation - code c0000005 (first chance)
> First chance exceptions are reported before any exception handling.
> This exception may be expected and handled.
> eax=000000af ebx=0166c6a0 ecx=ffffe0a8 edx=00002020 esi=01668050
edi=00002020
> eip=1f9ddfca esp=0188fafc ebp=0188fb64 iopl=0 nv up ei ng nz na pe
cy
> cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
efl=00010283
> *** ERROR: Symbol file could not be found. Defaulted to export symbols
for
> C:\WINNT\System32\SQLSRV32.dll -
> SQLSRV32!SQLSetEnvAttr+76b5:
> 1f9ddfca 83250000000000 and dword ptr [00000000],0x0
ds:0023:00000000=??
>
> The following is the output from windows debugger after attempting to run
> this query through our application
> (7d8.888): Access violation - code c0000005 (first chance)
> First chance exceptions are reported before any exception handling.
> This exception may be expected and handled.
> eax=000000af ebx=02007c98 ecx=ffffe0a8 edx=00002020 esi=02008780
edi=00002020
> eip=1f9ddfca esp=000e5594 ebp=000e55fc iopl=0 nv up ei ng nz na pe
cy
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010283
> *** ERROR: Symbol file could not be found. Defaulted to export symbols
for
> C:\WINNT\System32\SQLSRV32.dll -
> SQLSRV32!SQLSetEnvAttr+76b5:
> 1f9ddfca 83250000000000 and dword ptr [00000000],0x0
ds:0023:00000000=??
> Any insight into this issue will be greatly appreciated!

Access Update Query Problem

Looks like my suspicion was correct; in the join scenario, you're
dragging the complete recordset over and attempting to do the join
client side. If your data set is large (or your machine is
over-taxed), then it'll take a while to do the updates all at once.
In the second scenario (VBA), you're updating one record at a time on
the SQL Server, so the machine is not dealing with multiple records.
Does that make sense? As to how to fix it, not sure.
StuOn 7/29/2005 1:22 PM, Stu wrote:
> Looks like my suspicion was correct; in the join scenario, you're
> dragging the complete recordset over and attempting to do the join
> client side. If your data set is large (or your machine is
> over-taxed), then it'll take a while to do the updates all at once.
> In the second scenario (VBA), you're updating one record at a time on
> the SQL Server, so the machine is not dealing with multiple records.
> Does that make sense? As to how to fix it, not sure.
> Stu
>
In the join scenario, the msaccess process spikes the CPU but I/O is
stagnant. So I think there is a bug somewhere as the update join query
originally worked.
Dan|||On 8/1/2005 12:44 PM, Stu wrote:
> Which I/O? Disk or network? I don't think Access manages ODBC by
> writing it to a temporary file; I believe it tries to do it in-memory.
> I could be wrong about that.
>
Both.

Access to the remote server is denied because the current security context is not trusted.

Hello,

In SQL 2005, from a stored procedure in a local database I am attempting to execute a remote stored procedure in another database on another server. I am getting the error referred to in the Subject when the local stored procedure tries to execute the remote stored procedure. A couple of comments:

The remote database is set up as a linked server in the local database. As part of the linked server definition I selected the 'be made using this security context', and provided a local user name and password.

The remote database is set to Trustworthy.

I have tried every combination of WITH Execute As on the remote stored procedure but nothing works.

I can query against the remote database successfully within Management Studio. I can even execute the remote stored procedure successfully from within M.S., but not from within my local stored procedure when it is run.

Thank you for your help on this - Amos.

I assume you are using a Windows principal for the EXECUTE AS statement, correct? If that is the case, I think I know the problem. When using EXECUTE AS <windows_principal> there is no real authentication for the Windows user:

* If you have a OS older than Windows 2003, the Windows token would really be valid for SQL Server and not a real Windows token

* if you are using Windows 2003, and Kerberos is available, the system should use a S4USelf token and these type of tokens are, as far as I understand these tokens are restricted, and out of the box you should not be able to use them on another machine.

If your scenario falls under the S4USelf token, it may be possible to use delegation and use this token on the remote server (during the remote SP call), but I would personally not recommend it.I would prefer to suggest changing the EXECUTE AS clause to use a SQL principal (SQL authentication should work).

Remember that for remote calls to work with EXECUTE AS, it is necessary to trust the impersonated token on the server, turning on the TRUSTWORTHY bit on the source DB (the DB where the local SP resides) and making sure the DBO has AUTHENTICATE SERVER permission (if DBO is a member of sysadmin, this permission is implicitly granted).

Let us know if this information was of any help or if you have additional questions.

Thanks a lot,

-Raul Garcia

SDE/T

SQL Server Engine

|||

Raul,

Thank you for taking the time to answer. I am getting a bit desperate for an answer!

First let me say that I don't have a great deal of experience in this area (security). Therefore, I might be asking some pretty dumb questions. My first question is this. On my remote stored proc, do I have to use 'WITH EXECUTE AS'? I would rather not if I don't have to. I cannot get this to work whether I use it or not. So, let's start there. Can I get this to work with the Execute As?

Amos.

|||

You don’t have to use EXECUTE AS on the remote SP unless you want to. I am assuming you want to execute always under the exactly same principal (on the local DB) and that’s why you used execute as on the local SP, but as you will always connect as the same principal on the remote machine, using EXECUTE AS will be of little value.Even for the local SP, you don’t need EXECUTE AS unless you want to always use the same principal (i.e. use it as a proxy) to connect to the remote machine and execute the remote SP.

If you prefer, you can describe the problem you want to solve and I will do my best to help you find a solution.

Thanks a lot,

-Raul Garcia

SDE/T

SQL Server Engine

|||

Raul,

You are giving me too much credit :). I only used Execute As to try to get this to work. So, let's go under the assumption I don't need it. Here is my current setup now:

The remote stored proc does not have 'Execute As'|||

I can see one mistake here: the trustworthy bit is enabled on the remote server, but it should be for the local server. Also make sure that if the DBO for the local SP DB is not a member of sysadmin, to grant AUTHENTICATE SERVER to the DBO login.

The TW bit + AUTEHNTICATE SERVER will tell the local server that the impersonated context is valid across the SQL Server instance, and only then it can be used in remote calls.

BTW. What is the impersonated context (EXECUTE AS clause) being used? Is it a Windows principal or a SQL principal?

|||

Raul,

I don't know how to thank you! That was it. My local database was not set to Trustworthy. I actually thought about changing this yesterday but it didn't make any sense to me to do that so I didn't try it.

Amos.

|||

No problem, I am glad I was able to help you resolve this problem.

Please let us know if you have any further questions or feedback.

-Raul Garcia

SDE/T

SQL Server Engine

|||

For additional information on the TRUSTWORTHY bit, see the following whitepaper:

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

Thanks
Laurentiu

|||

Hi,

Great post, only it doesn't fix the problem that I am having. All the criteria above is true to my situation and I have run through the checklist described, but I still receve the "Access to the remote server is denied because the current security context is not trusted" error message.

Is there anything else that I can try?

Thanks

MIke

|||

thats got it.

The Authenticator of the trust is the DBO of the database, if the DBO is not a member of the target db (and trusted) then the error occurs.

By updating the source DBO to one that is trusted I now have working links.

Thanks for all your help peeps.

Mike

|||

Can you explain the solution in more detail?

I am having a similar problem:

I have a Linked server on a SQL 2005 database that connects to an Ingres DB

I am able to run stored procedures manually in management studio but when I schedule a job to run these procedures I get a similar error - Security context is not trusted.

I've set the local database to have Trustworthy bit on. But how can I set the remote server via the linked server object with the Trustworthy bit. Also I have the Security Context on the linked server - with the option - Connections be made with the following security context - and I have provided a username and password that has access to the remote database.

Thanks

Sg

|||

IIRC, I had to set both the local database and the remote database to Trustworthy. In addition, make sure the "RPC" and "RPC Out" options on the Linked Server defintion are set to True.

Amos.

Access to the remote server is denied because the current security context is not trusted.

Hello,

In SQL 2005, from a stored procedure in a local database I am attempting to execute a remote stored procedure in another database on another server. I am getting the error referred to in the Subject when the local stored procedure tries to execute the remote stored procedure. A couple of comments:

The remote database is set up as a linked server in the local database. As part of the linked server definition I selected the 'be made using this security context', and provided a local user name and password.

The remote database is set to Trustworthy.

I have tried every combination of WITH Execute As on the remote stored procedure but nothing works.

I can query against the remote database successfully within Management Studio. I can even execute the remote stored procedure successfully from within M.S., but not from within my local stored procedure when it is run.

Thank you for your help on this - Amos.

I assume you are using a Windows principal for the EXECUTE AS statement, correct? If that is the case, I think I know the problem. When using EXECUTE AS <windows_principal> there is no real authentication for the Windows user:

* If you have a OS older than Windows 2003, the Windows token would really be valid for SQL Server and not a real Windows token

* if you are using Windows 2003, and Kerberos is available, the system should use a S4USelf token and these type of tokens are, as far as I understand these tokens are restricted, and out of the box you should not be able to use them on another machine.

If your scenario falls under the S4USelf token, it may be possible to use delegation and use this token on the remote server (during the remote SP call), but I would personally not recommend it.I would prefer to suggest changing the EXECUTE AS clause to use a SQL principal (SQL authentication should work).

Remember that for remote calls to work with EXECUTE AS, it is necessary to trust the impersonated token on the server, turning on the TRUSTWORTHY bit on the source DB (the DB where the local SP resides) and making sure the DBO has AUTHENTICATE SERVER permission (if DBO is a member of sysadmin, this permission is implicitly granted).

Let us know if this information was of any help or if you have additional questions.

Thanks a lot,

-Raul Garcia

SDE/T

SQL Server Engine

|||

Raul,

Thank you for taking the time to answer. I am getting a bit desperate for an answer!

First let me say that I don't have a great deal of experience in this area (security). Therefore, I might be asking some pretty dumb questions. My first question is this. On my remote stored proc, do I have to use 'WITH EXECUTE AS'? I would rather not if I don't have to. I cannot get this to work whether I use it or not. So, let's start there. Can I get this to work with the Execute As?

Amos.

|||

You don’t have to use EXECUTE AS on the remote SP unless you want to. I am assuming you want to execute always under the exactly same principal (on the local DB) and that’s why you used execute as on the local SP, but as you will always connect as the same principal on the remote machine, using EXECUTE AS will be of little value.Even for the local SP, you don’t need EXECUTE AS unless you want to always use the same principal (i.e. use it as a proxy) to connect to the remote machine and execute the remote SP.

If you prefer, you can describe the problem you want to solve and I will do my best to help you find a solution.

Thanks a lot,

-Raul Garcia

SDE/T

SQL Server Engine

|||

Raul,

You are giving me too much credit :). I only used Execute As to try to get this to work. So, let's go under the assumption I don't need it. Here is my current setup now:

The remote stored proc does not have 'Execute As'|||

I can see one mistake here: the trustworthy bit is enabled on the remote server, but it should be for the local server. Also make sure that if the DBO for the local SP DB is not a member of sysadmin, to grant AUTHENTICATE SERVER to the DBO login.

The TW bit + AUTEHNTICATE SERVER will tell the local server that the impersonated context is valid across the SQL Server instance, and only then it can be used in remote calls.

BTW. What is the impersonated context (EXECUTE AS clause) being used? Is it a Windows principal or a SQL principal?

|||

Raul,

I don't know how to thank you! That was it. My local database was not set to Trustworthy. I actually thought about changing this yesterday but it didn't make any sense to me to do that so I didn't try it.

Amos.

|||

No problem, I am glad I was able to help you resolve this problem.

Please let us know if you have any further questions or feedback.

-Raul Garcia

SDE/T

SQL Server Engine

|||

For additional information on the TRUSTWORTHY bit, see the following whitepaper:

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

Thanks
Laurentiu

|||

Hi,

Great post, only it doesn't fix the problem that I am having. All the criteria above is true to my situation and I have run through the checklist described, but I still receve the "Access to the remote server is denied because the current security context is not trusted" error message.

Is there anything else that I can try?

Thanks

MIke

|||

thats got it.

The Authenticator of the trust is the DBO of the database, if the DBO is not a member of the target db (and trusted) then the error occurs.

By updating the source DBO to one that is trusted I now have working links.

Thanks for all your help peeps.

Mike

|||

Can you explain the solution in more detail?

I am having a similar problem:

I have a Linked server on a SQL 2005 database that connects to an Ingres DB

I am able to run stored procedures manually in management studio but when I schedule a job to run these procedures I get a similar error - Security context is not trusted.

I've set the local database to have Trustworthy bit on. But how can I set the remote server via the linked server object with the Trustworthy bit. Also I have the Security Context on the linked server - with the option - Connections be made with the following security context - and I have provided a username and password that has access to the remote database.

Thanks

Sg

|||

IIRC, I had to set both the local database and the remote database to Trustworthy. In addition, make sure the "RPC" and "RPC Out" options on the Linked Server defintion are set to True.

Amos.

Access to the remote server is denied because the current security context is not trusted.

Hello,

In SQL 2005, from a stored procedure in a local database I am attempting to execute a remote stored procedure in another database on another server. I am getting the error referred to in the Subject when the local stored procedure tries to execute the remote stored procedure. A couple of comments:

The remote database is set up as a linked server in the local database. As part of the linked server definition I selected the 'be made using this security context', and provided a local user name and password.

The remote database is set to Trustworthy.

I have tried every combination of WITH Execute As on the remote stored procedure but nothing works.

I can query against the remote database successfully within Management Studio. I can even execute the remote stored procedure successfully from within M.S., but not from within my local stored procedure when it is run.

Thank you for your help on this - Amos.

I assume you are using a Windows principal for the EXECUTE AS statement, correct? If that is the case, I think I know the problem. When using EXECUTE AS <windows_principal> there is no real authentication for the Windows user:

* If you have a OS older than Windows 2003, the Windows token would really be valid for SQL Server and not a real Windows token

* if you are using Windows 2003, and Kerberos is available, the system should use a S4USelf token and these type of tokens are, as far as I understand these tokens are restricted, and out of the box you should not be able to use them on another machine.

If your scenario falls under the S4USelf token, it may be possible to use delegation and use this token on the remote server (during the remote SP call), but I would personally not recommend it.I would prefer to suggest changing the EXECUTE AS clause to use a SQL principal (SQL authentication should work).

Remember that for remote calls to work with EXECUTE AS, it is necessary to trust the impersonated token on the server, turning on the TRUSTWORTHY bit on the source DB (the DB where the local SP resides) and making sure the DBO has AUTHENTICATE SERVER permission (if DBO is a member of sysadmin, this permission is implicitly granted).

Let us know if this information was of any help or if you have additional questions.

Thanks a lot,

-Raul Garcia

SDE/T

SQL Server Engine

|||

Raul,

Thank you for taking the time to answer. I am getting a bit desperate for an answer!

First let me say that I don't have a great deal of experience in this area (security). Therefore, I might be asking some pretty dumb questions. My first question is this. On my remote stored proc, do I have to use 'WITH EXECUTE AS'? I would rather not if I don't have to. I cannot get this to work whether I use it or not. So, let's start there. Can I get this to work with the Execute As?

Amos.

|||

You don’t have to use EXECUTE AS on the remote SP unless you want to. I am assuming you want to execute always under the exactly same principal (on the local DB) and that’s why you used execute as on the local SP, but as you will always connect as the same principal on the remote machine, using EXECUTE AS will be of little value.Even for the local SP, you don’t need EXECUTE AS unless you want to always use the same principal (i.e. use it as a proxy) to connect to the remote machine and execute the remote SP.

If you prefer, you can describe the problem you want to solve and I will do my best to help you find a solution.

Thanks a lot,

-Raul Garcia

SDE/T

SQL Server Engine

|||

Raul,

You are giving me too much credit :). I only used Execute As to try to get this to work. So, let's go under the assumption I don't need it. Here is my current setup now:

The remote stored proc does not have 'Execute As'|||

I can see one mistake here: the trustworthy bit is enabled on the remote server, but it should be for the local server. Also make sure that if the DBO for the local SP DB is not a member of sysadmin, to grant AUTHENTICATE SERVER to the DBO login.

The TW bit + AUTEHNTICATE SERVER will tell the local server that the impersonated context is valid across the SQL Server instance, and only then it can be used in remote calls.

BTW. What is the impersonated context (EXECUTE AS clause) being used? Is it a Windows principal or a SQL principal?

|||

Raul,

I don't know how to thank you! That was it. My local database was not set to Trustworthy. I actually thought about changing this yesterday but it didn't make any sense to me to do that so I didn't try it.

Amos.

|||

No problem, I am glad I was able to help you resolve this problem.

Please let us know if you have any further questions or feedback.

-Raul Garcia

SDE/T

SQL Server Engine

|||

For additional information on the TRUSTWORTHY bit, see the following whitepaper:

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

Thanks
Laurentiu

|||

Hi,

Great post, only it doesn't fix the problem that I am having. All the criteria above is true to my situation and I have run through the checklist described, but I still receve the "Access to the remote server is denied because the current security context is not trusted" error message.

Is there anything else that I can try?

Thanks

MIke

|||

thats got it.

The Authenticator of the trust is the DBO of the database, if the DBO is not a member of the target db (and trusted) then the error occurs.

By updating the source DBO to one that is trusted I now have working links.

Thanks for all your help peeps.

Mike

|||

Can you explain the solution in more detail?

I am having a similar problem:

I have a Linked server on a SQL 2005 database that connects to an Ingres DB

I am able to run stored procedures manually in management studio but when I schedule a job to run these procedures I get a similar error - Security context is not trusted.

I've set the local database to have Trustworthy bit on. But how can I set the remote server via the linked server object with the Trustworthy bit. Also I have the Security Context on the linked server - with the option - Connections be made with the following security context - and I have provided a username and password that has access to the remote database.

Thanks

Sg

|||

IIRC, I had to set both the local database and the remote database to Trustworthy. In addition, make sure the "RPC" and "RPC Out" options on the Linked Server defintion are set to True.

Amos.

Access to "C:/etc/etc/etc.rptproj.user" is denied

Hi All!!

I have recently come across the following problem when attempting to access the solution file for the project in question. I double click to access the file and VS2003 fires up, only for it to give me the above warning. At which point nothing is loaded in the tree!

When I check things out they do show up in Source Safe but if I need to add any new reports (which I do), I am unable to add them...

Cany anyone shed any light on the matter?

Thanks a million!!

I believe this answers your question:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=988559&SiteID=1

|||Issue been resolved thanks for the suggestion