netclectic wrote:

Don't knock if, not only does it have it's own programming language but it even has it's own DAY!!

LOL And I thought AMD fanboys go far in celebrating their product of love

Good morning! Looks like all of you Europians/Africans have already had a field day with my question. This whole global thing blows me away sometimes. BTW, Frans, would it be possible to display the post dates and times in a regional/time-zone adjusted manner? Really weird when I see posts at 15:39 and it's only 9:05. Hard to judge the timing of posts. Not a big deal.

In any event...Frans, we wouldn't need a strongly-typed collection - in fact the generic collection can be devoid of all other properties/methods except the .Fields property. I just need a way to create objects that can be used in a reporting scenario easily - something that allows me to "flatten" heirarchical objects for display.

This of course only applies to objects with a 1:1 relationship, but I think the next step would be to allow the inclusion of aggregates for objects in a 1:n relationship with the "primary" object. So you could add single columns for 1:1 entities, and add things like Sum(field) for 1:n objects.

The "generic" collection would have to allow for the "starting" table/entity so that we knew which "direction" to look at relationships - I could be wrong on that one, but it seems necessary.

In the absence of this type of solution - even if/when you implement aggregates, i'm still going to have to use stored procedures simply because creating detail reports with entity collections is very difficult, and creating new inherited collections for each report will be insane.

As for the issue of regenerating the LLBL. Here are the steps I have to take (had, I've since abandoned holding the generated files in source control). Its possible I'm making it overly difficult, so I'm curious to see your response:

1. Check out the LLBL from Source Control ( I use Vault )
2. Remove the project from the solution
3. Refresh the catalog (wouldn't be necessary for typed lists)
4. Regenerate the LLBL
5. Copy generated files to the VS project directory
6. Re-add the LLBL project to the solution
7. Change the assembly name in project settings since it doesn't line up with the namespace
8. Re-add all of the references to the LLBL (I have 10 other projects in the solution)
9. Check in the LLBL
10. Rebuild the solution
11. Hope everything pans out correctly.

Makes it worse because once all of that is done, the other programmer on the team must refresh his solution (Get Latest) which takes him forever (he's stuck with a very slow computer) and rebuild (which takes another eternity).

Then, to top it off, I have other projects (reports, actually - each in their own assembly) that depend on the LLBL assembly even though they are not part of the solution the LLBL is in. What's worse is that MS's file reference idiosyncracies cause major problems with it since everytime the LLB changes, the version number changes which requires me to re-reference it from every report project.

However, I have resolved many of the reference problems by setting "Copy Local" to false, and I know I could have avoided the problem completely by removing the auto-versioning feature, but I didn't. This doesn't help all of the other steps I have to go through.

In the past month or so, I've pulled the LLBL out of source control and into its own solution to eliminate the source control headaches. But every regeneration requires me to load up the solution and rebuild the assembly (I guess I could use command line here), then I post the assembly on a network share so my partner can access it and copy it locally.

Hope that helps with why I don't like regenerating the LLBL unnecessarily. I don't mind doing it for normal stuff - heck small price to pay for what I get in return - but eliminating places that I have to do it is important for us. Thanks.

Jeff...

jeffreygg wrote:

Good morning! Looks like all of you Europians/Africans have already had a field day with my question. This whole global thing blows me away sometimes. BTW, Frans, would it be possible to display the post dates and times in a regional/time-zone adjusted manner? Really weird when I see posts at 15:39 and it's only 9:05. Hard to judge the timing of posts. Not a big deal.

The time displayed is GMT + 1 (thus CET). I think your time is 7 hours behind our time.

In any event...Frans, we wouldn't need a strongly-typed collection - in fact the generic collection can be devoid of all other properties/methods except the .Fields property. I just need a way to create objects that can be used in a reporting scenario easily - something that allows me to "flatten" heirarchical objects for display.

That would result in a datatable like object . The problem is the properties for databinding. They're not there, the property descriptor factory has to produce these based on the fields collection. That's why I think if you simply fetch the data in a datatable using the typedlist fetch logic (but pass in your own entityfields object and relations collection), you're set.

This of course only applies to objects with a 1:1 relationship, but I think the next step would be to allow the inclusion of aggregates for objects in a 1:n relationship with the "primary" object. So you could add single columns for 1:1 entities, and add things like Sum(field) for 1:n objects.

The "generic" collection would have to allow for the "starting" table/entity so that we knew which "direction" to look at relationships - I could be wrong on that one, but it seems necessary.

In the absence of this type of solution - even if/when you implement aggregates, i'm still going to have to use stored procedures simply because creating detail reports with entity collections is very difficult, and creating new inherited collections for each report will be insane.

Specifying expressions for reporting is often problematic indeed. A sum/count aggregate with a groupby in a single table query is not that big, it is indeed a challenge when you have a multi-table query and aggregate on multiple fields, perhaps in a subquery etc.

As for the issue of regenerating the LLBL. Here are the steps I have to take (had, I've since abandoned holding the generated files in source control). Its possible I'm making it overly difficult, so I'm curious to see your response:

1. Check out the LLBL from Source Control ( I use Vault )
2. Remove the project from the solution
3. Refresh the catalog (wouldn't be necessary for typed lists)
4. Regenerate the LLBL
5. Copy generated files to the VS project directory
6. Re-add the LLBL project to the solution
7. Change the assembly name in project settings since it doesn't line up with the namespace
8. Re-add all of the references to the LLBL (I have 10 other projects in the solution)
9. Check in the LLBL
10. Rebuild the solution
11. Hope everything pans out correctly.

Ok, that's indeed not the way, some comments: 1. Check out the LLBL from Source Control ( I use Vault ). >>>>> This is not really required, if you opt for the edit/check in/merge way of doing sourcecontrol (ala subversion/cvs). Vault supports this. This has the advantage that you don't have locked files on disk. VSS does: check out/edit/check in)

1. Remove the project from the solution >>>>>>> Not required.

2. Refresh the catalog (wouldn't be necessary for typed lists) >>>>> Only do this when you have changed the DB.

3. Regenerate the LLBL >>>>>> This is your almost final step. Choose as destination directory the folder where your code is located, i.e. your work folder

4. Copy generated files to the VS project directory >>>>>>> Not required if you generate directly into hte working folder

5. Re-add the LLBL project to the solution >>>>>> Not required, as you didn't remove the project.

6. Change the assembly name in project settings since it doesn't line up with the namespace >>>>> Not required as the project file is not overwritten.

7. Re-add all of the references to the LLBL (I have 10 other projects in the solution) >>>>> Not required, as the project file is simply the same.

8. Check in the LLBL >>>>>> You can do this indeed. however in my scenario, add the new Typed list if you have added one, to the vs.net project. This will be done automatically in the upcoming update (now in beta)

Makes it worse because once all of that is done, the other programmer on the team must refresh his solution (Get Latest) which takes him forever (he's stuck with a very slow computer) and rebuild (which takes another eternity).

I think you can make your life easier by keeping the generated code in a separate solution, compile to an assembly and reference that assembly in your actual solution. This way, you don't have the burden of the generated code in your solution, which speeds up intellisense and compile time.

Then, to top it off, I have other projects (reports, actually - each in their own assembly) that depend on the LLBL assembly even though they are not part of the solution the LLBL is in. What's worse is that MS's file reference idiosyncracies cause major problems with it since everytime the LLB changes, the version number changes which requires me to re-reference it from every report project.

If you've signed your code, be sure to use own version numbers in the assemblyinfo file, so you don't get different build numbers.

In the past month or so, I've pulled the LLBL out of source control and into its own solution to eliminate the source control headaches. But every regeneration requires me to load up the solution and rebuild the assembly (I guess I could use command line here), then I post the assembly on a network share so my partner can access it and copy it locally.

I think this is the best choice. You can create a small .cmd file which first calls vsvars32.bat, then compiles the generated code on the command line and hten copies the dll to the network share in one go

I use such a .cmd file (bat file) to first pull all sourcecode out of subversion for the runtime libs, then call the separate build .cmds for the separate dll's, then copy the source and dll's to the distribution dirs. Makes life very easy.

Check this thread to see how to compile vb.net generated code on the command line: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=242

That would result in a datatable like object . The problem is the properties for databinding. They're not there, the property descriptor factory has to produce these based on the fields collection. That's why I think if you simply fetch the data in a datatable using the typedlist fetch logic (but pass in your own entityfields object and relations collection), you're set.

Are you saying this is available now, in Self-Servicing? Such a solution would be totally acceptable. Again, I don't need anything but a way to combine data into a single dataset

Ok, that's indeed not the way, some comments: 1. Check out the LLBL from Source Control ( I use Vault ). >>>>> This is not really required, if you opt for the edit/check in/merge way of doing sourcecontrol (ala subversion/cvs). Vault supports this. This has the advantage that you don't have locked files on disk. VSS does: check out/edit/check in)

1. Remove the project from the solution >>>>>>> Not required.

2. Refresh the catalog (wouldn't be necessary for typed lists) >>>>> Only do this when you have changed the DB.

3. Regenerate the LLBL >>>>>> This is your almost final step. Choose as destination directory the folder where your code is located, i.e. your work folder

4. Copy generated files to the VS project directory >>>>>>> Not required if you generate directly into hte working folder

5. Re-add the LLBL project to the solution >>>>>> Not required, as you didn't remove the project.

6. Change the assembly name in project settings since it doesn't line up with the namespace >>>>> Not required as the project file is not overwritten.

7. Re-add all of the references to the LLBL (I have 10 other projects in the solution) >>>>> Not required, as the project file is simply the same.

8. Check in the LLBL >>>>>> You can do this indeed. however in my scenario, add the new Typed list if you have added one, to the vs.net project. This will be done automatically in the upcoming update (now in beta)

Didn't realize the other way of using source control. I think that's the king pin for all of the problem. I'm pretty sure I resorted to removing and re-adding projects and all that jazz simply because of the source control issues. It also could have originated with source safe. Gosh, Source Safe is hideous.

I think this is the best choice. You can create a small .cmd file which first calls vsvars32.bat, then compiles the generated code on the command line and hten copies the dll to the network share in one go

I use such a .cmd file (bat file) to first pull all sourcecode out of subversion for the runtime libs, then call the separate build .cmds for the separate dll's, then copy the source and dll's to the distribution dirs. Makes life very easy.

Check this thread to see how to compile vb.net generated code on the command line: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=242

Sounds great, thanks!

Jeff...

jeffreygg wrote:

That would result in a datatable like object . The problem is the properties for databinding. They're not there, the property descriptor factory has to produce these based on the fields collection. That's why I think if you simply fetch the data in a datatable using the typedlist fetch logic (but pass in your own entityfields object and relations collection), you're set.

Are you saying this is available now, in Self-Servicing? Such a solution would be totally acceptable. Again, I don't need anything but a way to combine data into a single dataset

Yes. Actually, the TypedList code does this internally It constructs a ResultsetFields object (which is an EntityFields derived class, able to deal with aliases) and adds the fields to that one. Please peek inside a TypedList class and check out the BuildResultset method To fill your datatable, simply check out the Fill() method, it's pretty straight forward

[...] Didn't realize the other way of using source control. I think that's the king pin for all of the problem. I'm pretty sure I resorted to removing and re-adding projects and all that jazz simply because of the source control issues. It also could have originated with source safe. Gosh, Source Safe is hideous.

It's another way of looking at things but when you start using that other way, hte cvs/subversion way, it's great.

jeffreygg wrote:

Didn't realize the other way of using source control. I think that's the king pin for all of the problem. I'm pretty sure I resorted to removing and re-adding projects and all that jazz simply because of the source control issues. It also could have originated with source safe. Gosh, Source Safe is hideous.

Re sourcesafe: we use it in house (even though we all hate it, but the "management" won't move away from it ). Anyway, i'm the sole person on the project responsible for generating the llblgen bits, so i just keep the whole llblgen project bits checked out to me and only check them in (and immediatlely check them out again, so i don't forget to check them out next time) when there's been an update.

This approach has worked ok so far.

Hi Frans,

Just a friendly question, which school did you go to?

Thanks.

netLearner wrote:

Hi Frans,

Just a friendly question, which school did you go to?

Thanks.

VWO (higher highschool, gymnasium) then 2 years Computer Science on a high profile university (University of Twente) but after 2 years I didn't want to become a researcher so I moved to the HIO (Higher Education of Computer Science) which is a small step below the high profile university I was on and more practical oriented (i.e. not research oriented) and got my B.sc degree in computer science in 1994 . The high profile universities lead to M.Sc. degrees. (it's hard to explain the dutch levels of education to other countries as every country has different levels of 'universities'. The HIO called itself a university, and by american standards it is (it's at the same level as a state university I think).