You probably clicked the checkbox for the trusted connection instead of typing in the MAS_Reports password.  (This breaks the report for anyone who doesn't have SQL read permissions for their Windows login).

In CR, click File - Summary Info, remove the Keywords, save, close and run from Sage again. 

You should be prompted to convert the report, which might fix the data source.

Thank you for the response. I followed the instructions and had user run from sage and they were prompted to convert the report (which they did) but after still received the same error message.  The strange thing in the past this has not been an issue for modifying crystal reports and I don't believe I changed any settings since it started.

That you! Following your instructions worked.

Hello! I'm having the same issue, but we're executing a stored procedure using Command. Any suggestions there?

First, this question is completely unrelated to the question above (report data source)... you'd be better off posting a new question.

Second, I never recommend direct SQL data edits.  (Use a VI import instead, using InvoiceNo and HeaderSeqNo as your key).

Third, I have never used that Command technique so I can't comment on how it works / limitations.

Well we were getting the same database failure error so I thought it might be related.. but thank you for answering!

You're trying to do more than just run a custom report: different.

That should work jut fine.  what is the error message?

ensure that you are connecting to the right server, database and that your parameters are properly mapped

And ensure that the user has exec permission on the proc and update permissions on the table

GRANT EXEC ON dbo.UpdateCustomerPONo to MAS_Reports

Updating raw Sage 100 transaction history directly in SQL is a bad idea. 

There is no business logic validation, nor logging as an audit trail.  Editing a Customer PO# is relatively harmless, but I just won't open that door where users expect that kind of dangerous functionality.

VI enforces permissions and business logic.

We have a unique business situation where customers consistently give us incorrect PO numbers, so we added a UDF field for the "new" PO number so that we could retain the original information as well as the new PO and display both on their invoice :)

I'm not saying you're doing a bad thing.  I've edited UDF data via SQL script before, with tightly controlled security (...I know what is safe / not safe, and limit the type of solutions I deploy accordingly).

I mainly wanted to post a warning here for the benefit of any future readers of this thread.  Direct SQL edits are to be avoided.

I'm not saying you're doing a bad thing.  I've edited UDF data via SQL script before, with tightly controlled security (...I know what is safe / not safe, and limit the type of solutions I deploy accordingly).

I mainly wanted to post a warning here for the benefit of any future readers of this thread.  Direct SQL edits are to be avoided.