Crystal Reports

Epicor ERP 10
, ,
21

We originally installed the 2012 Native Client on our client machines.

22

I installed the SQL Native Client but it still didnā€™t work. So I added the user to database and it works. Did you also have to do that?

23

No, I didnā€™t have to do that. If it was truly using the creds in the company maintenance you would think it would workā€¦ I see that they intended that field to work in that way, but I am as confused as you are. I wouldnā€™t think you need to add a user to the database every time. Also if you donā€™t control that carefully they could query any able they want.

24

I wonder how anyone else here with ADO connections handles it so the user doesnā€™t have to put in the passwordā€¦

25

Your reports are just using the creds in Company Maintenance?

26

Yeahā€¦ thatā€™s why Iā€™m not real excited about adding users to the dB. Would rather just have the single user in Company Maintenance. But canā€™t get that to work. Iā€™m very confused as to why it doesnā€™t. As according to the Epicor Help it should.

27

We finally figured out a working solution on this. Thanks @utaylor for the help!

For others trying to get Crystal Reports to run from within E10. We had to install the SQL 2012 Native Client along with the Crystal Reports runtime. We also had to add the users to the E10 dB with db_datareader permissions. E10 doesnā€™t seem to pickup the creds in Company Maintenance. Not ideal from a security standpoint but it will work for now.

Iā€™m going to do some more testing and see if I can get the report to run without a username/password in Company Maintenance. Will save the username/password in the report. Also going to open a ticket with Epicor Support about the ODBC issue.

1 Like
28

We have crystal reports running within E10 and never used odbc settings on company maintenance. In fact the field is blank.

Vinay Kamboj

29

What are you using for your connection type in the Crystal Report?

30

Thru ado/xml

Vinay Kamboj

31

You must be using Crystal Reports with RDDs and not directly to the database then?

1 Like
32

All our reports are either RDD or BAQ reports.

Vinay Kamboj

1 Like
33

Ah, yes. Ours are direct to the dB. Not using RDD or BAQs.

34

And @utaylor didnā€™t share with you the risks of going directly to the database?

Utah, tsk tsk. @Vinaykamboj knowsā€¦

:popcorn:

1 Like
35

We are aware of the riskā€¦ itā€™s a temporary thing.

1 Like
36

What are these risks?

Asking for a friend ā€¦ :wink:

2 Likes
37

In all honesty I have been wanting to get with a report pro to see how they would avoid going to the database directly in some situations. I try my hardest not to directly query the database. I didnā€™t say anything to @chaddb because he was already doing it and I assumed he knew the risks.

1 Like
38

We are aware of the risk. But we didnā€™t see another way to create the report we needed.

1 Like
39

Hey, at least we ā€˜canā€™ directly access our database. :stuck_out_tongue_closed_eyes:

40

Just giving you :poop: Utah. Iā€™m sure @ckrusen has witnessed the :fireworks: about the pros and cons of going directly to the database. The risks are well documented in this forum:

  • Bypasses all application level security (company, territory, buyer, etc.)
  • Increases attack surface to your database
  • Shared passwords are hard to manage. (You will change them every so often and update all of the reports, right?)
  • Small but non-zero risk of missing data in cache and not yet flushed to the database
  • Epicor has some views that you should use instead of the actual tables
  • Might have to create views to get to PatchFld fields and those views have interfered with upgrades
  • More explanations required to the SOX auditor if you are a public company

EVERYONE on your network can directly access your database! :kissing_heart: