?
Solved

Pass formula results from Main Report to SubReports

Posted on 2009-02-18
45
Medium Priority
?
3,052 Views
Last Modified: 2012-07-12
I'm trying to pass the results of a formula (result is a Date) to two subreports.  The subreports use that result as part of their record selection, but it seems like nothing is being passed.  The links are setup correctly as far as I can tell.

Based on some of the results I found via search, I may have to do something with a variable, but I've only used those once, and I haven't been able to figure it out on my own.
0
Comment
Question by:uwhc
  • 18
  • 15
  • 4
  • +2
44 Comments
 
LVL 3

Expert Comment

by:Cootser
ID: 23671639
Hello
In the main report create a formula with a shared variable

eg:

whileprintingrecords;
shared datevar mydate := {table.field} // or wherever the date comes from

an assign a value to it in that formula.

Then, in each of the sub reports you can use that shared variable again

eg

whileprintingrecords;
shared datevar mydate;

so each sub report has its own formula
in each new formula where you want to use a shared variable you need to declare it, as above
also put the whileprintingrecords; command in there as well

It is important that the main report formula that creates the shared variable is in a section above where the sub reports are

so

RH - create shared variable
RF - sub report uses shared variable //or some thing like that

now you should be able to use the date from the main report in either of the sub reports
0
 

Author Comment

by:uwhc
ID: 23671844
Can't use it in Record Selection but was able to use it to Suppress sections however.
0
 
LVL 101

Expert Comment

by:mlmcc
ID: 23671951
If you need it in the record selection try this.

In the main report add a formula
whileprintingrecords;
shared datevar mydate;
mydate

You should be able to link the subreport on that formula

mlmcc
0
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
LVL 3

Expert Comment

by:Cootser
ID: 23671971
if you can use the formula to suppress sections in the subreport, can you use it to calculate / display in those same sections?

what sections is the formula visible in?

do you have the whileprintingrecords; in there?

spelling ok?

0
 
LVL 3

Expert Comment

by:Cootser
ID: 23672006
mlmcc , would uwhc need to create a parameter in the subreports to link to
0
 

Author Comment

by:uwhc
ID: 23672128
This is the formula I used in the main report for the variable:

Whileprintingrecords;
Shared DateVar advar;
advar := {@AutoDate}

And in each subreport:

Whileprintingrecords;
Shared DateVar advar;

But the subreport variable formula isn't an option when I got into Record Selection (which is why I went the suppression route).

mlmcc - what would I do with that formula beyond that?  At some point I'd have to get it to equal my @AutoDate.

Just fyi, @AutoDate is setup to determine how many days to go back when run on a weekday, CurrentDate-3 for Monday, CurrentDate-1 for the rest.
0
 
LVL 3

Expert Comment

by:Cootser
ID: 23672303
Hello

create a date type parameter in your sub report
then in the main report right click on the sub report and choose change sub report links

The Field To Link to should be AutoDate

the sub report parameter field should be the new param that you have created (you may need to scroll down to see this)

Then in your record selection you can use your parameter

Best regards

Cootser
0
 

Author Comment

by:uwhc
ID: 23672573
I think the reason I can't get this to work is that the @AutoDate formula is a 'IF' formula, so it may not being recognized as a Date value?
0
 
LVL 101

Expert Comment

by:mlmcc
ID: 23673484
Actually you can link it to the date field in the subreport.
You can then change the subreport record selection to be what you really need.

mlmcc
0
 
LVL 35

Expert Comment

by:James0628
ID: 23677351
IF-ELSE's, etc. in a formula don't generally matter.  If @AutoDate produces a date value, CR will see it as a date value.  You can test this simply by putting that formula on the report and seeing what kind of formatting options you have for that field, or by simply holding the mouse over the field for a second and seeing what field type CR shows at the end of the tooltip that pops up (assuming that you have tooltips enabled, eg. under View > Tooltips).

 If @AutoDate produces a date, you should be able to link it to a date parameter/field in the subreport, but it might depend on exactly what's in @AutoDate.  Can you post the formula?

 James
0
 

Author Comment

by:uwhc
ID: 23682156
@AutoDate:
if {@DayofWeek} = 2 then {@PreviousFri} else {@PreviousDay}

{@PreviousFri}:
CurrentDate-3

{@PreviousDay}:
CurrentDate-1
0
 
LVL 35

Expert Comment

by:James0628
ID: 23688083
Did you try Cootser's last suggestion of creating a date parameter in the subreport, using that parameter in the record selection in the subreport and then linking @AutoDate to the date parameter in the subreport?

 Or, instead of creating a parameter in the subreport, you could add @AutoDate to the subreport links and tell CR to select data in the subreport by comparing a field in the subreport to @AutoDate (which I think may be what mlmcc was suggesting in his last post).

 I can't tell exactly what you've tried so far, but if you tried one of those and were not able to get CR to link @AutoDate to the parameter or field, it may be because of the data types.  CR recognizes both a Date and a DateTime data type.  In some situations they're interchangeable, with CR converting one if necessary, but when creating subreport links, they are not.  You're using CurrentDate in your formulas, so @AutoDate returns a Date.  If the parameter or field in the subreport is a DateTime, CR will not let you link @AutoDate to it.

 There are various ways you could handle that, depending at least in part on whether or not the time in the DateTime is significant.  If you don't care about the time, the simplest thing (although not necessarily most efficient) would probably be to change the DateTime in the subreport into a Date, eliminating the time from the equation and allowing CR to link @AutoDate to that date.  I can't really be more specific without knowing more about your subreport (mainly, what you're trying to compare @AutoDate with).

 James
0
 

Author Comment

by:uwhc
ID: 23691357
This is what I've tried, with little success:

1)  Create variable on main report:
Whileprintingrecords;
Shared DateVar advar;
advar := {@AutoDate}
2)  In subreport, added variable:
Whileprintingrecords;
Shared DateVar advar;
3)  PROBLEM:  the subreport variable formula is not available in record selection
4)  WAS ABLE TO use suppression formula using variable instead, but this seems inefficient

1)  Create formula in main report for AutoDate
2)  Link Autodate to Date parameter within subreport
3)  PROBLEM:  subreports always come up blank, as if the value is not being passed.  I've tried all possible link options and no change.

1)  Create variable formula in main report for AutoDate
2)  Link variable Autodate to Date parameter within subreport.
3)  PROBLEM:  subreports always come up blank, as if the value is not being passed.  I've tried all possible link options and no change.  The linking in this also seems, well, just wrong, as I can't even see the Date parameter I created, it only offers up a new one put there by the system.
3)  PROBLEM:  subreports always come up blank, as if the value is not being passed
0
 
LVL 35

Expert Comment

by:James0628
ID: 23691945
Item #1 in your second list:

 > 1)  Create formula in main report for AutoDate

 If @AutoDate is a formula, why are creating another formula for it?
 If the AutoDate that you referred to there is something else, what is it?


 Item #3 in your third list:

 > The linking in this also seems, well, just wrong, as I can't
 > even see the Date parameter I created, it only offers up a
 > new one put there by the system.

 That sounds like the problem I described, where the data types are different (eg. the formula in the main report outputs a date, but the parameter in the subreport is a datetime).


 When you try to link a formula to the subreport, have you tried putting the parameter (or whatever you linked the formula to) somewhere on the subreport (eg. in the report header) so that you can see if it got the right value?

 James
0
 
LVL 35

Expert Comment

by:James0628
ID: 23691985
Oh, yeah.  I didn't think to mention this until after I posted that last message, but you could always attach your report to a message here so that we can take a look at it and check the formulas, subreport links, etc.  If you can post a report with saved data, we can also run some tests.  But, of course, the data should not include anything "sensitive".

 James
0
 

Author Comment

by:uwhc
ID: 23693331
Apparently *.rpt isn't an allowed file type so I can't attach it...

1)  I created another formula for it because I couldn't get the original formula to work via the subreport link.  Was just grasping at straws essentially...

2)  I checked the parameters, everything is set to 'Date' so I don't know why it doesn't work.  Like I said I even tried using the parameters it wanted to build when the link was created (I assume these would be setup as Date), and no change.
0
 

Author Comment

by:uwhc
ID: 23695616
0
 
LVL 35

Expert Comment

by:James0628
ID: 23697750
Sorry.  Forgot to mention that you need to change the extension.

 First of all, there's basically nothing in the main report.  No datasource at all.  Any particular reason that you have two subreports and nothing (except a couple of headings) in the main report?  Just wondering.  I don't see anything really wrong with what you're doing.  It just seems a little odd to me.

 The subreport link looks OK.  Your AutoDate formula and parameters are dates and the subreport record selection is comparing to a date (a string field converted to a date).

 My guess is that there's a problem in the record selection in the subreport.

 Are you sure that Asgnmnt.DateAssign and Asgnmnt.TimeAssign are valid date and time strings (meaning that they will be correctly converted to dates and times by the Date and Time functions)?

 You're checking a number of fields in the subreport record selection.  Could any of those ever be null?  Nulls can cause problems in CR formulas and you need to check for them (using IsNull), _before_ you do any other tests on that field.  For example, something like:

not IsNull ({Asgnmnt.DateAssign}) and
{Asgnmnt.DateAssign}<>'' and

 The specific code you use will depend on how you want to handle the null values.  In the simplest case, it's just a question of whether or not you want to include those records on the report.


 If you don't see anything specific in the record selection that you think might need to be changed (eg. a field that might be null), I'd suggest you try eliminating various conditions and see if/when data shows up in the subreport.  That will tell you if one or more of your conditions are causing the problem.

 James
0
 

Author Comment

by:uwhc
ID: 23710633
>>First of all, there's basically nothing in the main report.  No datasource at all.  Any particular reason that you have two subreports and nothing (except a couple of headings) in the main report?  Just wondering.  I don't see anything really wrong with what you're doing.  It just seems a little odd to me.

I've had to put together some subreports that use completely different datasources together in one main report, so I've just made a habit of not adding a datasource to the main report if I don't have to to get results.  Does that have a negative impact in some way I'm unaware of?

>>Are you sure that Asgnmnt.DateAssign and Asgnmnt.TimeAssign are valid date and time strings (meaning that they will be correctly converted to dates and times by the Date and Time functions)?

They are actually strings which can be converted with some custom functions for that datasource, but I prefer to avoid that if possible.  That's why I threw in the <>'' for each so I only get records where they are not Null.  This has always allowed me to use the standard Date function to convert them in the past.

Were you even able to pass the @AutoDate at all to the one of the subreports, even just to display?  I haven't.  
0
 
LVL 35

Expert Comment

by:James0628
ID: 23712177
> Does that have a negative impact in some way I'm unaware of?

 None that I'm aware of.  The biggest concern with using subreports seems to generally be the potential overhead you can have if you end up with a subreport that is run too many times (eg. for every record in the main report) and/or reads too many records.  You don't have that problem with what you're doing.

 The only other basic limitation of what you're doing is that a subreport can't have subreports, so you can't use this report as a subreport, which I assume is not a big problem for you.


 > That's why I threw in the <>'' for each so I only get records
 > where they are not Null.

 Could they actually be null, or just an empty string?  Those are two different things.  If they may actually be null, you should include the IsNull test.  Technically, when you're dealing with a record selection formula, that _might_ not be necessary if the record selection is being passed to the server, but even if it is being passed to the server, I'd include the IsNull test, just to play it safe.
 If your "null" is really just an empty string, then you're fine.


 > Were you even able to pass the @AutoDate at all to the
 > one of the subreports, even just to display?  I haven't.

 The link and subreport record selection that you have _look_ fine.  I think I was able to view the report at work, but here at home, it prompts me to set up a datasource for it (even though the report has saved data) and I get no output.  What are you using for a datasource?  What kind of database?  I think I may need to create an ODBC connection for that db (although that's just a guess).  I'll try the report again at work tonight (I work nights).


 FWIW, I had no problem changing the record selection in the "pended no reason.rpt" subreport to use the AutoDate parameter instead of Pm-@AutoDate, and then linking the AutoDate formula in the main report to the AutoDate parameter in the subreport.  But I couldn't actually test that (even at work), because when I changed the record selection and/or the subreport link, CR wanted to re-read the datasource and, of course, it couldn't do that.


 But, like I said, what you had looks like it should work, so my guess is that there's some other problem in the record selection in the subreport.  If you don't see anything wrong, I'd try eliminating conditions from the record selection one at a time and see if/when data shows up, to see if one or more of those conditions are causing the problem.

 James
0
 
LVL 35

Expert Comment

by:James0628
ID: 23712291
Oh yeah, one more thing on the subject of nulls vs empty strings.

 You can eliminate the need to check for nulls in most CR formulas by checking the "Convert Database NULL Values to Default" option in the report options, but I'd still check for them in record selection formulas.  I think those formulas may be a special case.  It just seems like I've had a situation where I had the option turned on and a record selection formula still didn't work properly without a test for nulls.  So, if a field could be null, I'd play it safe and check for that in a record selection formula, even if that option is on.

 James
0
 

Author Comment

by:uwhc
ID: 23712487
It's a SQL2K database (HEAT from FrontRange).

As far as I've seen, 'null' is never used, everything that is null is actually just an empty string.

I'm still confused about how the record selection could be having an effect on the subreport link data being sent.  If I can't get it to even just display on the subreport, something else has to be going wrong I would think?
0
 
LVL 35

Expert Comment

by:James0628
ID: 23712670
> I'm still confused about how the record selection could
 > be having an effect on the subreport link data being sent.

 Well, it shouldn't.  The link looks OK, so I'm guessing that if you're not getting data on the subreport, it's because of something else in the subreport record selection.

 > If I can't get it to even just display on the subreport,
 > something else has to be going wrong I would think?

 Yeah, it would seem so.  I wish I could remember what happened when I tried the report at work.  I think it ran, but I can't remember the details.  At home, I don't get any output because it immediately wants to read data.  I'm not sure why.  FWIW, I'm using CR 10 in both places.  Like I said, I'll try it again at work tonight.

 James
0
 
LVL 35

Expert Comment

by:James0628
ID: 23717777
OK, I was wrong.  I can't view the report at work either.  As soon as I open the report, CR prompts me to select a datasource.  Since I don't have your datasource, I cancel out of that, and I get no report.  I thought it had worked here simply because I couldn't remember it failing, but it does.  I'm not sure why, if the report has saved data.  You could try saving the report with data again and reposting it.

 All I can say at this point is that the AutoDate link that you have looks OK, but I can't actually test it.  You have the {?Pm-@AutoDate} parameter on the "pended no reason.rpt" subreport and for today (Monday), I would expect it to show last Friday's date.

 Just for the heck of it, I'd try "simplifying" the AutoDate formula.  It uses several other formulas and they're not necessary.

if DayOfWeek (CurrentDate) = 2 then CurrentDate - 3 else CurrentDate - 1


 I've had problems trying to use formulas in formulas.  Generally, it seems to be fine, and I wouldn't expect problems with what you have, but it's easy enough to try it without the other formulas, just to see what happens.

 James
0
 

Author Comment

by:uwhc
ID: 23735224
No dice on the simplified formula.
0
 
LVL 35

Expert Comment

by:James0628
ID: 23740399
You've probably already said, but if you run the report with {?Pm-@AutoDate} on the subreport, what do you get for that parameter?

 I don't know why I can't view your report.  I can view other reports that have been posted on EE with saved data.  Can you try attaching the report with saved data again?

 If anyone else is reading this, have you tried opening the report that uwhc posted?

 James
0
 
LVL 101

Expert Comment

by:mlmcc
ID: 23741699
I get the same problem.  My only guess is that it is because the subreport is open in design mode.

Try closing all tabs except the main design and preview

mlmcc
0
 
LVL 35

Expert Comment

by:James0628
ID: 23743744
It's worth a try, but I don't think that's the problem.  At least some of the reports posted in the thread below have two subreports open in design mode, but I have no problem viewing those reports:

http://www.experts-exchange.com/Database/Reporting_/Crystal_Reports/Q_24163164.html

 James
0
 
LVL 35

Expert Comment

by:James0628
ID: 23743798
Of course as soon as I sent that, I thought of something else.  :-)

 If he's having a problem with his subreport link, I wonder if that's forcing CR to try to read data for the subreport as soon as you open the report, or something like that?


 uwhc,

 I'm beginning to think that there may just be something wrong with the report.  In my experience it's very rare, but I have had situations where CR just seemed to have a problem with a report, like something in it was corrupted or something.  You could try saving your two subreports as separate reports, creating a new main report and adding those two subreports to the new report (or maybe start by just adding one of them).  If that doesn't work, you could try starting over from scratch, but that's kind of a last resort.

 James
0
 

Author Comment

by:uwhc
ID: 23746094
Started over, only used the 'pended' subreport.  I can't get ANYTHING via a formula to pass to the subreport.

Tried things as simple as a Date and nothing.
0
 
LVL 35

Expert Comment

by:James0628
ID: 23752229
If you put the linked parameter in the subreport on the subreport, what does it show?  Or are you not getting any output from the subreport at all?

 The basic idea is sound.  I've linked formulas in a main report to parameters in a subreport and had no problems at all.  Actually, I just tried it again.  I used formulas to pass values to several parameters in a subreport.  Some were literal values and some were datetime fields converted to dates (the corresponding parameters in the subreport were type Date).  I even used CurrentDate - 35 in one formula (35 because that happened to give me data on that subreport) and it worked fine.

 Can you try saving the report with data again and reposting it?  Also, while I don't think that that's the problem, you could make sure that the subreports were not opened in the design view, as mlmcc suggested.  No harm in trying.

 James
0
 
LVL 11

Expert Comment

by:stevengraff
ID: 23763259
Keep in mind that in the HEAT database dates are not stored as actual datetime fields -- they're stored as characters. I think they do this for the sake of portability, i.e. HEAT's back-end database can be either SQL or Oracle, or whatever they want it to be at some point in the future.
0
 
LVL 35

Expert Comment

by:James0628
ID: 23766496
That shouldn't be a problem as long as CR can recognize the string as a date.  In the subreport that we're talking about (there are two on the report), he uses CR's Date function to convert a field to a date and that's what he's trying to compare with the date that's linked from the main report.

 James
0
 
LVL 11

Expert Comment

by:stevengraff
ID: 23766536
OK. I just thought maybe if the subreport is querying the database and trying to find stuff by date, that that might be the problem, since the subreport is returning no data.
0
 
LVL 35

Expert Comment

by:James0628
ID: 23768036
It was worth mentioning, but it doesn't seem to be the problem here.

 James
0
 

Author Comment

by:uwhc
ID: 23785655
I tried without the subreport being opened.  Made no difference.

Maybe there's something wrong with my install.  I can't make heads/tails of what actual version of 11 I'm currently running, and I've never seen a mroe complicated process for attempting to update...
send-info-to-subreport.txt
0
 
LVL 35

Expert Comment

by:James0628
ID: 23791412
By "opened", we meant that the subreport was opened in the design view.  I say that because in the report that you just posted, you've actually removed the second subreport completely, and the first subreport is still open in the design view.  Also, closing the subreport wasn't supposed to change anything on your end.  mlmcc suggested that we might be able to view the output from your report (instead of CR immediately prompting us for a datasource) if the subreport design view window was closed.  I think he'd agree that it was a longshot, but it was worth a try.

 The interesting thing is that I _am_ able to view the output of the report that you just posted, with the same subreport open in the design view and the second subreport removed, so it would appear that there was something about the second subreport that was causing CR to immediately try to read data when the report was opened (even though there is saved data).  Maybe the subreport links are off or something?  Whatever it was, at this point I don't _think_ it has anything to do with your problem.

 When I view the report, I see that the subreport is blank.  This is interesting, because in CR 10, even if I have a subreport that finds no records to output, I still get the subreport headers and footers on the main report.  But I don't see those on your report.  I don't see anything that would suppress them.  I suppose it may just be something different about how CR XI reports work, but that seems unlikely, since I'm running the report in CR 10.

 I'm not sure what to make of that.  Hopefully mlmcc will get a chance to take a look at the report and maybe he'll have some ideas.

 James
0
 
LVL 11

Expert Comment

by:stevengraff
ID: 23795432
By any chance are the main report (and all subreports) all drawing data from the same database (i.e. HEAT)?
0
 

Author Comment

by:uwhc
ID: 23795445
The main report has no datasource.
0
 
LVL 11

Expert Comment

by:stevengraff
ID: 23802125
Does the report run if you eliminate all record selection? I know that's not what you want at the end of the day, as you'd have too much data. But if you get data at all, then that points to the selection formula being faulty.

Also, not to beat a dead horse, if you're selection is comparing a date and a string, and you're doing a conversion on one or the other, I'd be suspicious of that.  HEAT stores date as varchars in format yyyy-mm-dd, i.e. 2009-03-04.
0
 

Author Comment

by:uwhc
ID: 23804838
Eliminate record selection in which, the subreport?  The subreport works fine as long as I don't try to use the linked value in it.

I've been building HEAT reports for some time.  Every indication is that Crystal believe what I am giving it is a Date.
0
 
LVL 35

Accepted Solution

by:
James0628 earned 2000 total points
ID: 23816324
OK, I've been doing some testing here and I think I'm finally getting a handle on this.

 You said that you've had other reports where the main report had no datasource and the work was done in subreports.  I take it that in those reports, you didn't have anything linked to the subreports?

 The problem seems to be using links to a subreport when the main report doesn't read any records.

 "Doesn't read any records" can mean that the main report has no datasource at all; or that it has a data source, but doesn't actually use any of the fields from the datasource; or that it has a datasource, but has a record selection that eliminates all of the records from the report (eg. checks a field for a value that will never be found in that field).  I get the same results from all of those scenarios.

 The problem has nothing to do with the record selection in the subreport.  If I create a main report as described above, create a formula containing a literal value, and link that formula to a parameter in the subreport that is actually not used _anywhere_ in the subreport, the subreport doesn't show up.

 The simple act of creating a link to a parameter in the subreport, when the main report does not read any records, causes the subreport to not show up.  If I change the main report so that it reads at least one record, or remove the subreport link, the subreport shows up.  The main report doesn't have to actually show any records.  They can be suppressed.  It just has to read something.

 I don't know why this is happening.  I can't see any reason why a main report that doesn't read any records shouldn't be able to link to a subreport, so at this point I'm inclined to think that it's some kind of bug/design flaw in CR.


 So, it looks like if you change the main report to read something - anything - the subreport should show up.  I'd suggest something small/convenient, where there either simply aren't many records for the main report to read through, or where you can easily limit it to a small number or records.  Keep in mind that you can't simply use a record selection that eliminates every record.  The main report has to actually read at least one record.

 Another possibility would be to move one of your subreports into the main report.  If you only link to one of the subreports, you could move that one into the main report, thereby eliminating the linking issue.  Otherwise, as long as what was now in the main report was always going to read at least one record, you should be able to link to the remaining subreport, if necessary.


 One other thing, which just didn't occur to me until this morning.

 Why are you linking to that subreport in the first place?  All you're passing it is a date based on the day of the week.  The subreport could calculate that just as easily.  If you want to see it on the main report, you could just calculate it both places.  Admittedly, if you thought that this was something that you might be changing in the future, it would be a little easier if there was just one formula to worry about, but it's not like changing two formulas would be difficult.

 I'm kind of embarrassed that I didn't think of that earlier, but I was focused on trying to figure out why the link wasn't working.  It's normally such a simple thing.  It just turns out that it doesn't work in your specific circumstances (a main report that doesn't read any records).

 James
0
 

Author Closing Comment

by:uwhc
ID: 31554878
Gave the main report a datasource, put one field in the Details section, and the subreport now works.  Thanks!
0
 
LVL 35

Expert Comment

by:James0628
ID: 23817291
Great.  Sorry it took so long to figure out.  It's just something that I don't recall running into before and it's normally such a simple thing, I really couldn't see how it could _not_ be working.  It wasn't until I started testing some things here that I finally started to figure out what was going on.  I was really surprised when I saw the same problem show up in a report here (I had actually already started working on a reply saying that I thought that your report was broken.  Had to scrap that and start over :-).

 Anyway, I'm glad we finally got it working.

 James
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

There have always been a lot of questions related to when Crystal Reports evaluates report components (such as formulas, summaries, cross-tabs, charts, to name a few examples). Crystal Reports uses a two-pass reporting process to provide greater …
Hello everyone, Hope you find this as helpful as we did. We have on the company I work for an application built in Delphi V with Crystal Reports 8. We all know that Crystal & Delphi can be temperamental sometimes and the worst thing is, nearly…
this video summaries big data hadoop online training demo (http://onlineitguru.com/big-data-hadoop-online-training-placement.html) , and covers basics in big data hadoop .
Screencast - Getting to Know the Pipeline
Suggested Courses

807 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question