There are certain Crystal Reports features that cannot be combined in the same report, for example SQL command objects and server side grouping. However, as far as I can find, the built-in help doesn't seem to clearly document these conflicts. For example, checking the help page for either of those features doesn't mention that it doesn't work with the other. I want to be able to find out about these conflicts when I decide to use a new feature, not later when I go to use some other feature and the option is greyed out. Is there any place that documents these conflicts?
I am specifically working with Crystal Reports XI. Bonus points if the list of conflicts documents what range of versions each feature is available and conflicting in.
I have now also checked the release notes (release.pdf on install CD), and it does not have any answers to this question.
I have not found these anywhere, my suggestion is to create a test/dummy report, make something painfully simple that runs what your trying together.
This is of course no guarantee that is will work once you get all your real data in there. But I've upvoted your question, cause I'd like to see those doc's myself.
For installation notes and details
regarding known issues with this
release, please refer to release.pdf
on the Crystal Reports CD.
How about the Known Issues list? Did you find anything there?
Related
I was trying to find a way to manually add data for the said tables but I couldn't find it. I also tried searching in google but I couldn't find a correct answer either.
Do you guys know what table do they represent? Thanks!
You can't create course sites without having defined at least one academic term; if you haven't done so, Sakai leaves you in the cold, and the only way to fix it is to populate the database table in question, CM_ACADEMIC_SESSION_T, manually, by using an INSERT query.
The Sakai documentation doesn't explain how to do this, or whether it really suffices, but you can ask the sakai-dev mailing list or go by the answers to this question provided there in the past (e.g. here or here) and hope they still apply. (This is typical for Sakai.)
An alternative is not to use course sites at all (I didn't trust them after discovering this) and use project sites instead.
This is a general question about the topic. I ran across a post which gave VB script code for version control. I've been developing with Access for a while, but have learned entirely on my own and can be pretty ignorant of the the broader IT world. I got
the code to work for me, but I'm lost on how to put it to work as a system.
To give some context, I have an example situation that maybe this kind of thing could solve. I'm now working on two versions at once (1.2 and 1.3) because the first version we'd like to release has to be tested where it's to be used in China. They were out of the office for a week due to the Chinese new year, in the meantime, I'm working on 1.3. Now, any changes I have to make to 1.2 of course have to go into 1.3. Actually, it's worse than that because clarity over the fact that we'd have to do this in two separate releases didn't emerge until work had been done which in hindsight went further than we could incorporate in 1.2.
The code in the post basically dumps all of the info about forms, reports, VBA, and macros into a bunch of text files (for some reason not tables, and maybe that has something to do with the fact that I'm working with Access 2010 rather than whatever version this code was created for.) Apparently, it can then reconstruct an application from those same text files.
What do I need to understand about source code control to make such a thing work for me? I recognize that might not be something you'd want to explain in a post, but can you point me in the right direction information-wise?
While this question is 3 years old, it might be of interest to some to have an answer anyway.
AFAIK, accesssvn.codeplex.com -cited by #Robby Shaw - is not working and not maintained.
Today I see 2 products usable products for VCS inegration:
one is https://github.com/timabell/msaccess-vcs-integration which is quite active
the other one is Microsoft Access 2010 Source Code Control for which I don't know if it works with more recent versions of Access
Apart from VCS, you could also use a database compare tool like Microsoft's Database Compare 2013
Also worth considering, Accdbmerge, a tool to merge 2 databases.
I am using iTextSharp to read pdf file. I am using pdfreader.GetPageContent() and PdfTextExtractor.GetTextFromPage() methods using simple text extraction strategy.
Both the methods not reading all the pdf's.
For one pdf if I use GetTextFromPage it's throwing Index was outside the bounds of the array exception(that page having bullet marks and special chars).
How to solve this problem ?
Recently a few bugs were fixed, so you have two options:
Wait for 5.1.4 to be released
Download and build the latest SVN yourself.
If you still have issues after building the latest SVN, either submit a bug report at sourceforge or subscribe to the mailing list and post there.
The recent bug fixes may or may not fix your specific problem. People keep complaining about the parsers, but many are unwilling to submit sample PDF(s) that reproduce the issue.
In other words, if the fixes don't solve your problem and you're unwilling to submit a bug report and sample PDF(s) you're out of luck.
Given a project I'm about to start there will be documentation produced.
What is the best practice for this?
Should the documents live with the code and assets or should there be a separate documentation store?
Edit
I'd like a wiki but I will need to print the documents etc... It's a university project.
It really depends on your team. Where I work, we keep documentation in a wiki which is linked in with our team website. For the purposes of shipping documentation, the wiki can be exported and we run it through a parser that "fancifies" the look and feel of the documentation for customer purposes.
Storing the documentation with the code (typically in your source repository) is not a bad idea. Just make sure to keep them separated. For example, keep a docs folder which is on the same level with your src folder in your repository. This way, you can quickly ship the current documentation, you can easily track revisions, and anybody new to the project can immediately jump in without having to go to multiple locations for information.
Storing it in source control is fine.
This is an interesting question -- basically, what others are saying is right about generated documentation, source files and templates/etc. should be stored in source control and generated during your build process.
As far as requirements/specs/etc. documentation, I have worked both ways, and I very much prefer using SharePoint or a Wiki/document portal that is designed for document sharing/versioning. The reason is, most non-developer folks aren't comfortable working with source control systems, and you don't gain any of the advantages of intelligent merging if you are using a binary format like Word. Plus it's nice to have internet-based access so you can reference and work on the docs in a distributed team without people having to install extra software.
Here's a 2017 summary of the options and my experience:
(extreme 1) Completely external (e.g. a wiki, Google Docs, LaTeX, MS Word, MS Onedrive)
People aren't bothered about keeping it up to date (half of them don't even know where to find the page that needs updating since it's so out of the trenches).
wiki platforms are “captive user interfaces” - your data gets stored in their proprietary schemas and is not easy to examine with a simple text editor (Confluence is even worse in that you have no access to the plaintext content at all anymore)
(extreme 2) Completely internal (e.g. javadoc)
pollutes the source code, and is usually too low level to be of any use. Well-written source code is still the best form of low level documentation.
However, I feel package-info.java files are underutilized.
(balance) Colocated documentation (e.g. README.md)
A good half way solution, with the benefits of version control. If a single README.md file is not enough, consider a doc/ folder. The only drawback of this I've seen is whether to source control helpful graphics (e.g. png files) and risk bloating the repo.
One interesting way to avoid this problem is to use plaintext diagram tools (I find Grapheasy and Text Diagram to be a breath of fresh air).
plaintext can be easily read even if your rendering engine changes as the years go by.
Github's success is in no small part thanks to its README.md located in the root of the project.
One tiny disadvantage of this approach though is that your continuous integration system will trigger a new build each time you make edits to the README.md file.
If you are writing versioned user documentation associated with each release of the product, then it makes sense to put the documentation in source control along with its associated product release.
If you are writing internal developer documentation, use automated internal source code documentation (javadoc, doxygen, .net annotations, etc) for source level documentation and a project wiki for design level documentation.
I think most of us in the industry are not really following best-practices and it of course also depends a lot on your situation.
In an agile environment where you would have a very iterative process of release, you will want to "travel light". In this particular case, Jason's suggestion of a separate Wiki really works great.
In a water-fall/big bang model, you will have a better opportunity to have a decent documentation update with each new release. Also you will need to clearly document what version of the requirements was agreed on and have loads of documentation for every tiny change you do to requirements (due to the effects it has on subsequent stages). Often if the documentation can live together with the version controlled source code it is the best.
Are you using any sort of auto-documentation or is it completely manual? Assuming that you are using an auto-documentation system, the documentation is more or less generated on the fly, and would be part of the code itself.
To me, (assuming that it's possible with whatever code you are using), this would be the preferred method of handling it, as you wouldn't need to maintain the documentation source at all.
I do alot of bugfixing and implementing new features for several different customers. These customers all report their bugs, change requests and new feature request into our Trac system.
Sometimes these requests result in me creating some SQL change scripts, sometimes there are Excel documents or Access databases with testdata, Word documents from the customer and so on. Alot of files that are used to fix one ticket and then can be deletede when the ticket is closed.
I usualy do this by creating folders in the filesystem like this: /customerXX/TicketNNNNN and then just dumping everything in there.
How do you organize your workfiles? Have you found some fantastic tool to do this?
I would say for scripts or files that are related to a particular ticket, the best thing to do would be to attach the file to that ticket in your issue tracking software - almost all issue trackers that I've worked with will allow you to do this. That way, you can look back and a) see exactly what you did in case something goes wrong, or b) do exactly the same thing if the issue comes up again later. That's almost certainly the best place to keep files with extra info from the customer, too (or at least the first place most people will look).
For frequently re-used scripts that aren't specific to a particular ticket, I would create a scripts/ or bin/ directory in the associated project, and keep them in there.
I also have a small handful of useful files that I keep in src/misc/ off my home directory, with things like SQL queries to get readable "explain" output out of Oracle and such, that aren't specific to any particular project. The number of these is small enough that subdirectories aren't necessary, though - I suspect if you ended up with a large number of these files, many of them could/should be moved to specific projects or your issue tracking system.
JIRA has been quite helpful for this at my site. It supports issue tracking, file attachments,and you can easily customize and categorize your projects and issues.
I use Fogbugz and I add all file to the case. I believe that no matter what application you use, The important is to keep this files for future references. If your bug-tracking tool does not let you attach file then add the files to the version control.
We use CaWeb4 and find it very easy to use for our bug tracking.