CliRefresher problem

Posts   
 
    
Pablo
User
Posts: 81
Joined: 21-Mar-2005
# Posted on: 14-Dec-2013 23:54:04   

Validating project... Project validation successful.

=====================

Exception caught.

Message: Project 'TopLib.DAL' requires DDL SQL update script export prior to relational model data refresh. Please load the project into the designer and pe rform this action from the designer. Source: CliRefresher Stack trace: at SD.LLBLGen.Pro.Tools.CommandLineRefresher.Startup.StartProcess(String projectFile, String userId, String password, Boolean overwriteCredentials, DatabaseT ype dbType, Boolean showErrorLog)

I'm working database first. We don't need llblgen to produce ddl sql script. I'm trying to get the clirefresher to work as part of our workflow, where we simply run a small script to update our DAL dll after fiddling with the database.

I've seen the problem reported before ... but no answers / solutions. I don't know how to solve this, any suggestion would be very much appreciated.

Regards, Paul

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 16-Dec-2013 00:03:26   

Hi Paul,

What version are you using? What is the change that triggers the need of the Update DDL script.

Please check the following thread, it's related: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=22351

David Elizondo | LLBLGen Support Team
Pablo
User
Posts: 81
Joined: 21-Mar-2005
# Posted on: 16-Dec-2013 17:31:36   

Version 4.1 What change? No change.

I'm working with a database and a corresponding DAL. 100% in sync (I did not notice any problem/discrepancy anyway).

The problem occurs everytime when I run CliRefresher (eventough i did not change anything).

Paul

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 17-Dec-2013 07:03:54   

Hi Paul,

The message about the the DDL Update is for some reason, that's why I asked you to check your project in the designer. Maybe it's a good idea to generate the UPDATE script to see whether or not it's relevant. The CliRefresher does this to avoid you to lose model changes.

Said that, if you want to ignore/skip the DDL Update Script, you will have to create your own version of the CliRefresher. Is very simple:

  1. Grab the Source Code zip from the customer area
  2. Open the CliRefresher project and fix the references.
  3. Comment the those lines at Startup.cs:236
if(projectToRefresh.CheckIfDDLSQLExportActionIsRequired(driverId))
{
    //throw new ApplicationException("Project '{0}' requires DDL SQL update script export prior to relational model data refresh. Please load the project into the designer and perform this action from the designer.".AsFormatted(projectToRefresh.ProjectName));
}
  1. Rebuild and replace the .exe into the LLBLGen installation folder.
David Elizondo | LLBLGen Support Team
Pablo
User
Posts: 81
Joined: 21-Mar-2005
# Posted on: 17-Dec-2013 16:40:28   

Daelmo, thanks for your reply. It indeed showed an error with a uc on a table. After removing that, the CliRefresher.exe did work. Thanks for pointing me to the DDL to find out the cause of the problem.

I tried another problem ... removing on puprose a pk from another table, and that error is shown as output from CliGenerator.exe ... Nice. When I fix the problem in the database though, it did not refresh/regenerate properly without going back to the designer....

Pablo

Pablo
User
Posts: 81
Joined: 21-Mar-2005
# Posted on: 17-Dec-2013 16:53:28   

I found a simple but rather silly workaround.

I created project file using the designer. I Refreshed the model and generated the code. Everything working fine, a DAL generated properly.

Next step was to delete all entities from the project in the designer.

Save the project file as 'empty' project file...

My refresh script now performs the following steps: 1. Copy empty project file to the project file we're going to use in the next steps. 2. Refresh with the newly copied project file 3. Regenerate with the newly copied project file

I tried this script with removing and adding the primary key, also with renaming tables....

it did seem to work ... please tell me if this introduces problems which are to be avoided!

Walaa avatar
Walaa
Support Team
Posts: 14946
Joined: 21-Aug-2005
# Posted on: 17-Dec-2013 18:32:17   

My refresh script now performs the following steps: 1. Copy empty project file to the project file we're going to use in the next steps. 2. Refresh with the newly copied project file 3. Regenerate with the newly copied project file

I don't understand what is being done here.

Pablo
User
Posts: 81
Joined: 21-Mar-2005
# Posted on: 18-Dec-2013 11:09:07   

Walaa,

what I'm doing there is avoiding the problem of not being able to refresh as a result of an error in the model. The solution is silly, but (AFAIK) can't be done another way using v4.1 ...

Database first approach requires a refresh after an error in the model has been detected (THATS A GOOD THING). The only problem is that V4.1 does not allow refreshes as long as there are errors in the model.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 18-Dec-2013 12:58:16   

I don't like having to repeat myself simple_smile so I refer to what I said in another thread about the same issue: http://www.llblgen.com/tinyforum/GotoMessage.aspx?MessageID=126550&ThreadID=22414

Frans Bouma | Lead developer LLBLGen Pro
Pablo
User
Posts: 81
Joined: 21-Mar-2005
# Posted on: 18-Dec-2013 13:06:17   

Otis, the solution (how ugly it may sound/look) used here simply works. It implements the use-case scenario database-first. IMHO LLBLGEN should support the same thing if desired by the user, as it did in past versions! (It worked perfectly uptil v2.6)

You looking away from this issue simply confirms that Database First is a dead-end street as far as llblgen is concerned? Reason: trust me, it's not possible. Right!?!

We'll see where this leads us ...

For the record: I also don't LIKE to repeat myself ...

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 18-Dec-2013 14:22:01   

Pablo wrote:

Otis, the solution (how ugly it may sound/look) used here simply works. It implements the use-case scenario database-first. IMHO LLBLGEN should support the same thing if desired by the user, as it did in past versions! (It worked perfectly uptil v2.6)

ah, so it should get rid of a validation system and go back to the v2.6 system which could lead to problems at runtime, which we then have to answer here on the forums, not you. It's easy to say 'it should do this', while at the same time you don't have the responsibility for the downsides of what 'this' is. If it was simple, we'd have fixed it long ago, like I said elsewhere. It's not, unfortunately. You don't seem to believe me, which saddens me, but what can I do? In the past 12 years I'm now working on the code base I've always put the customer first, if they have a problem I would invest to solve it and make their lives a tiny bit better, but I can't do things which are impossible. Like I said elsewhere: an invalid model can't be proven to migrate successfully so using it is then a gamble, which means if there are problems we have to answer them and solve them, as our code caused it, not you. So we choose to use code which can be verified, as a valid model can be migrated to a different schema. You're not happy with the downsides of this choice, I get that, however it is what it is.

For what it's worth, there is more time wasted in the threads you started based on this issue than it took to correct the pk issue in the project by far. wink

You looking away from this issue simply confirms that Database First is a dead-end street as far as llblgen is concerned? Reason: trust me, it's not possible. Right!?!

I never said those things in that context, so don't make it appear I did. I explained a couple of times why things are the way they are and that the particular issue you run into is actually an edge case, see the link above. Database first isn't a dead end street, it's one of the ways to define a model. There is a small issue which you ran into, which has several ways to correct it, you want to do it another way, which isn't possible, as explained elsewhere and you keep insisting it is.

Like I said, I wished I could add this, but that's not possible: a model has to be valid to be migrated. In v2 the term 'valid' model didn't exist as there was no validator AND the model did accept entities without a PK. As I said elsewhere if that rule would have been present there already, it would have been a problem in v2 too.

We'll see where this leads us ... For the record: I also don't LIKE to repeat myself ...

I said that to not have to type it here again.

I don't know what's wrong here, I clearly explained why things are the way they are, that they're not ideal, that I understand your frustration but that it's also a minor issue which has some ways to fix it. I also don't know what you mean with 'We'll see where this leads us ...'. If you're afraid we'll kill off database first, you are mistaken: we'll never do that, as a lot of our customers work that way.

Frans Bouma | Lead developer LLBLGen Pro
Pablo
User
Posts: 81
Joined: 21-Mar-2005
# Posted on: 18-Dec-2013 16:55:38   

ah, so it should get rid of a validation system and go back to the v2.6

1 remarks to this: 1) No that is NOT what I'm suggesting. The extra validation is king! I appreciate it, a lot!! The earlier in the process the bug is detected, the better. Your remark makes me think that you simply still don't understand my reasoning. Maybe that on its own is the reason for lengthy and unproductive threads. Did you notice you put words in my mouth several times of which later I said that simply is not what I'm saying? Maybe it is my writing ... maybe it is your reading.

2) I said 'IMHO' which is an abbreviation for In My Humble Opinion! It's absolutly not my opnion that you must listen to me because I'm a customer. Don't worry. I appreciate you as a vendor.

I never said those things in that context, so don't make it appear I did.

I did not claim that you said those things, so don't attack me for putting words in your mouth. It is only true that I concluded those things.

I don't know what's wrong here

I do.

If you're afraid we'll kill off database first, you are mistaken: we'll never do that

I hope you prove me wrong. For the record ... I'm addicted to database first.