I have a number of Crystal Reports (9) report files that are distributed with a legacy VB6 application. When distributing the application to different customers i'd like to make sure that the original servernames and login information is not contained in the .rpt-file anymore. The login information is set in the code anyway.
As soon as i try to remove the Connection information in Crystal Reports Designer all the table and file information gets lost, too :(
I don't think there is a way to do what you are asking in the CR designer, since within the connection are your objects included in the report. No connection, no objects (as you've already discovered).
We use CR7 and CRXI in a production environment for software that is distributed to thousands of clients. All reports are developed using a private data location that is not accessible from the outside world. Even if someone managed to gain access, their efforts would be fruitless since no sensitive data is contained within the dev server. Credentials to production environments should never be kept with a report file unless that report file is used ONLY for that environment and nobody else's.
At the very least I would advocate creating another instance of the DB server if having another dev machine isn't possible, that way at least your log-on credentials do not point to a production environment. I've never personally had to do this, so if you decide to go this route and need help I suggest asking the folks over at ServerFault.
Related
I work in a construction projects company developing autocad tools, mostly with the integrated vba editor.
The company wants to keep the developed dvb files stay inside the company, or somehow make them useless when they are carried outside.
So, I know that be password protecting the created dvb files, the code can be hidden (Although after 5 min of google search I discovered that it is trivial to unlock them.) I am trying to find a way that the developed vba files will be used and executed in office, however their codes will be hidden and the employees would not be able to use them out of office.
I am not sure if this is possible though. I know that if I develop external exe files I can use several methods(Connect to local server before running, use USB stick key etc..), however I wonder if I can guarentee that the codes I wrote in the AUTOCAD VBA editor will not be seen and can not be used outside office.
Thank you for all the help in advance.
P.S: Using Autocad 2010 on Windows 7 SP1
In short, you cannot completely protect your DVB source files. As you discovered, information on breaking the password protection is readily available and trivial for a tech savvy user to do.
If your goal is to prevent users from just taking the DVB file with them and using it elsewhere (without source modification), you can embed some checks into the code which will cause failure. For example, ping your Domain Controller by name and if no response it returned, stop with an error. This, however, could be removed if someone edited the code (see first point above).
If you do need protection on your source, you don't want to go the DVB (which is VBA code) route. Instead you will want to develop a true plugin with .NET (which would require a re-write). Of course this isn't foolproof either as .NET code can be easily decompiled to source; however if you run it through a good obfuscator it would make it difficult (but still possible) for even the most dedicated to modify.
In short, there is no way fully protect your source, only make it more difficult for someone to reverse engineer.
I am an Epicor and Crystal Reports Newbie. I have started working with these programs a month ago, when I was hired. I am still trying to figure out how you know whether you are trying to customize a BAQ, Dashboard, etc. How to know where/when to make a new BOM report and such. If anyone out there has some tips, I would greatly appreciate it. I feel slightly intimidated by the program but am also determined to learn my way through it.
Thanks!
Toohey! Welcome to the world of Epicor!
Although I'm sure in the past couple of months you have learned the ropes, here are some extra tips to keep you moving forward:
That is not part of the system functionality
In order to keep costs under control, err on the side of not making system customizations to meet all user requests. You will quickly see that adding a quick field as a customization to a form isn't just the 5 minute change it seems like. You will soon be creating several custom reports and dashboards to report off of this field, and the cost of the change soon outweighs the benefit in many situations. As you become more familiar with this, try to balance ROI against the high cost of Epicor system customizations. It is best to lead with "that is not part of the system functionality", and when they push the issue, treat even small changes as controlled projects.
BAQ and Report Changes
Inevitably, you will need to customize the system's BAQs and Reports to meet your business needs because the standard system isn't designed exactly for your business.
Epicor has standard BAQs that start with 'z' and many reports. You should avoid editing the stock BAQs and reports, because they will be overwritten with each patch of Epicor. Instead, copy the standard distribution BAQs and rename the copies using your company initials as a prefix. Similarly, you want to create a custom reports folder separate (or within) the standard reports folder where you place all of your modified reports. You can then link the menu to the BAQ Report or Report Data Definition, and link the report style to the location of your new custom report on the server.
Customizations
Maintenance of customizations has a high long-term cost if you do not have in-house developers. A critical piece of advice here is to make sure all of the code, be it in C# or VB, is thoroughly commented. Even if you're generating code with a wizard, do yourself a favor and put a standard header into the script of every customization that includes the first date of the customization, when it was modified, and detail everything that was changed (especially if the change was a property change or a field addition that does not clearly appear in the script). Customizations have been known to fail for unexplained reasons, or create bad script that is not editable through the standard Epicor interface, and there may come a time when you have to rebuild the customization from scratch using only this change log and things you can clearly see in the form. You should save your customizations with some obvious standard naming convention (something like ORDER_ENTRY_CSR_YYMMDD), and make sure you update all menus to reflect the newest customization for the purpose you're using it. We also export our customizations for archival, just in case something should happen. Another note here is if you do not increment the customization name on a change and then update the menu items, users will still be use locally cached versions of the page until they clear their client cache. So, I always recommend incrementing. Another note on customizations and every custom exportable object in Epicor is to do yourself a favor and export them to either a source control system or a file repository so that after you deploy a faulty customization, rolling back to the previous version is quick and painless.
BPM Directives
As you're probably aware by now, BPM directives are powerful tools which can be used to update tables and prevent users from making terrible business decisions. A note on these is similar to customizations - comment comment comment!
Consultant Use
If you are using external consultants to create BPMs or Customizations, mandate distribution of commented source code that can be understood internally by one of your team members.
I hope this helps!
Source: 4 yrs experience as an Epicor ERP programmer
I would like to add that you should develop any Customization, BPM or Baq/Dashboard in the test system because any error on a solution can stop users from perform their job. Also, you can use a powerful tool called tracing options that helps you to recognize where to place the BPM directives. Further more there is a huge Epicor forum where you can post questions and a comunity of consultants , developers and users will answer your questions, and advise you about best Epicor practices, and it is completely free. You need to register on it; this is the link www.e10help.com.
I'm leading a small software development team (4 people), and have just broken ground on a source-controlled SQL Server 2008 database project, with isolated development databases for each developer. I'm still implementing this one step at a time, but I'm envisioning each developer having their own database, with a naming scheme something like <ProjectName>_DEVELOPMENT_<TFSUserName>. This was all recommended per the MSDN articles I've been reading, but someone let me know if that sounds way off.
Anyway, we have a shared application solution that we've been developing for some time. In the past, we had no database version control, and just modified our database directly from SQL Server Management Studio when new reference data needed to be populated, or when we were testing functionality -- one change immediately affected everyone else. So with this new change, I'm wondering what the best way would be to have each person connect to their isolated development databases from the application solution. Prior to isolated databases, our connection to the database was specified in our application's web.config as a connection string. If we're each going to have our own database, the only way I can see it working is for each developer to set their connection string in their local solution to point to their personal database. But changing the web.config will check out that file in the solution, so developers will always have to specifically uncheck that file when checking in application changes to the baseline. Is there a less clunky way for each developer to use their isolated database when doing application testing?
I recommend that you not make the database names username-specific. Instead make the database the same name for each developer and always reference it via localhost (localhost\<ProjectName>_DEVELOPMENT). Then the same connection string will work for every developer.
MSDN's suggestion to use username-specific databases is better for a shared development environment. It's definitely not ideal for a localized environment.
We're an SME with SAP implemented. We're trying to use the transactional data in SAP to build another system in PHP for our trucking division for graphical reports, etc. This is because we don't have in-house expertise ABAP development and any SAP modifications are expensive.
Presently, I've managed to achieve our objectives with read-only access to our Quality DB2 server and any writes go to another DB2 server. We've found the CPU usage on the SELECT statements to be acceptable and the user is granted access only to specific tables/views.
SAP's Quality DB2 -> PHP -> Different DB2 client
Would like your opinion on whether it is safe to read from production the same way? Implementing all of this again via the RFC connector seems very painful. Master-Slave config is an option for us but again will involve external consultancy.
EDIT
Forgot to mention that our SAP guys don't want to build even reports for another 6-months - they want to leave the system intact. Which is why we're building this in PHP on the top.
If you don't have ABAP expertise, get it - it's not that hard, and you'll get a lot of stuff "for granted" (as in "provided by the platform") that you'll have to implement manually otherwise - like user authentication and authority management and software logistics (moving stuff from the development to the production repository). See these articles for a short (although biased) introduction. If you still need an external PHP application, fine - but you really should give ABAP a try first. For web applications, you might want to look into Web Dynpro ABAP. Using the IGS built'in chart engine with the BusinessGraphics element, you'll get a ton of the most custom chart types for free. You can also integrate PDF forms created with Adobe Livecycle Designer.
Second, while "any SAP modifications are expensive" might be a good approach, what you're suggesting isn't a modification. That's add-on development, and it's neither expensive nor more complex than any other programming language and/or environment out there. If you can't or don't want to implement your own application entirely using the existing infrastructure, at least use a decent interface - web services, RFC, whatever. From an ABAP point of view, RFC is always the easiest option, but you can use SOAP or REST as well, although you'll have to implement the latter manually. It's not that hard either.
NEVER EVER access the SAP database directly. Just don't. You'll have to implement all the constraints like client dependency or checks for validity dates and cancellation flags for yourself - that's hardly less complex than writing a decent interface, and it's prone to break every time the structure is changed. And if at some point you need to read some of the more complex contents like long texts, you're screwed - period. Not to mention that most internal or external auditors (if that happens to be an issue with your company and/or legal requirements) don't like direct database access to a system as critical as this one, which again can cause lots of trouble from people you really don't want to mess with. It's just not worth it.
I am a frequent R user (the very first program I turn on everyday when I back to office is RStudio and I spend >50% of time using R to do manipulation, tabulation and visualization of data). Sometimes I need to get involved in the data collection process of various research project, that is I need to develop a database with frontend to facilitate a clerk, or someone with little sense in programming/database to do the data entry job.
Since most of the data collection process involve manually inputting a questionnaire with more than 50 questions (100 - 200 columns when they presented as a spreadsheet), and there are relationship between different questionnaire (e.g. questionnaire A collect information from a shop, and questionnaire B collect information from the staff inside that shop), initially I use Access 2007 for the development. Access 2007 does the job, but only fairly.
My major complain on Access 2007 is as follow:
developing the front-end is painful: after using R for long, I really hate using mouse to drag and drop boxes, and enabling some certain functions of a checkbox
fair/poor multi-user support in my opinion: if I am the only one who use the Access 2007 program, I am fine with it, but things start to change now, we have multi-user logon to add/update/remove data at the same time, since the database is developed by someone else, I always fear that the data may get corrupted
keep "reinventing the wheel": the database developer build the user login module in Access 2007 all by himself, but should this be something of a standard that I can get it from somewhere?
auto-compress the database and the database is VANISHED: yes, I do mean vanished, I tried it once, and it freaks me out, now I backup the access database all the time
In summary, I lost faith in Access 2007 to build a decent database for several staff (at most 20) to do the data entry/query work. So I turn to other options.
I am thinking of something like a "web-based" replace of Access 2007, xataface comes to me at first, but it doesn't seem like a complete solution for me, it can fix some of my problem now, but may not be so for other problems.
Then I googled quite a bit: xataface -> nuBuilder -> Drupal -> Web Application Framework. Since I don't find an exact alternative for Access 2007. I guess Web Application Framework is a way out.
In the Web Application Framework domain, I come across many names: CakePHP, RoR, Django, since I am not exactly a program/database/web developer, and I know nothing about PHP, Python, Ruby. I don't know which one I should choose. Or should I learn the language before go to the framework?
Can anyone enlighten me here? I can provide additional information if needed. Thanks.
Try looking into VFront and nuBuilder. These allow you to build front ends to MySQL databases (i.e. forms, reports, etc.).