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.

Using a named DSN can also break a report's functionality (for users on a machine without that DSN configured).

Either way, to fix a broken data connection, this is what I do.  (Sage may have some other recommendation...).

Find a custom report that works... open in CR and do a Database - Verify Database.  Type in the MAS_Reports password when prompted (avoiding the Integrated Security checkbox... never use that).

Don't save changes, closing the functional report, while leaving CR open.  Now open your broken report and click Database - Set Datasource Location. 

Reassign each table in your report to use the equivalent table in the active connection you made above... it will be shown with a little plug icon in the My Connections list.

Save, having replaced the broken data connection with one you know does work.

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.

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.