Jon,

However when you do that (which we were doing too) Crystal will need to connect to SQL server using that DSN. This means a few things.

1. There will be another connection to SQL server for this user, that ads overhead.

2. The user will need to log into the SQL server (if they are not using NT auth, which we recommend to our users but won't require)

3. The crystal reports login will need adequate rights to the data to run the report.

By using the same connection as the application, we have eliminate all of the above three issues. As far as issue 3, we use an app role for our ap, so a user only needs select rights on our config tabel to use our ap, once they are logged in, the app role is envoked and the connection has db_owner rights, all security is handled by the aps security system at this time.

Does this make sense to ya?

BOb


>>Ok,
>>
>>I am looking for an API of some kind so that I can use to get a connection handle to pass to crystal reports. I don't think the VFP connection handle is exactally what crystal is looking for.
>>
>>Thanks,
>>BOb
>
>Bob,
>
>Our application here calls Crystal runtime to launch reports against VFP data. I don't have to go so far as to get a connection handle. All Crystal cares about is a DSN whose data matches up to what was used to originally design the report.
>
>In the case of using Crystal's RDC object model, it's a matter of looping through the database table objects in the report and calling the SetLogonInfo method.
>
>If you're using Crystal differently, I'd certainly be interested in knowing what you are doing!
>
>Laterness,
>Jon