I created an app based on postgresql data source with multiple database schema. The tables were inferred with the name format schematable hence the default method was getschematable and all works well. BUT I go back and infer the same data source again to include some new tables, SOME of the original tables get inferred as table instead of schematable which breaks the code on the existing pages using getschematable.
Is there something that I am not understanding here or is this a bug? It seems crazy that I have to go back and fix the code everytime I infer the data source.
I too have had issues with this, though haven't had any schema changes for a few weeks, so maybe better now? I'd just like to know how I can reliably add a table or relationship, or change an existing table without the project getting hosed. Clearly changing anything referenced by the project's code is going to cause problems, but about just adding new stuff, or changing stuff that isn't referenced by code? What should I do and not do when modifying a data source to prevent unwanted changes?
1 Like
In our case, just adding one column to a database view and inferring that broke everything.
That said I think what broke it was forgetting to select the tables in a schema then inferring which automatically changed the model and the designer did the works on the radzen desigenr.cs for the pages immediately. That's on me but why does Radzen include the schema in the table name sometimes but not others?? If it was consistent then fixing by re-inferring would have worked fine.
1 Like
@SloSuenos, do you experience the same problem? If yes send us a complete application together with the steps required to reproduce the problem. The information provided so far is not sufficient for us to act.
1 Like
Looking into this in more detail, I see that the actual issue is that Radzen seems to miss something in pre-selecting the tables and views when you select 'Infer Schema'. I have to remember to manually select all the tables that I am using before selecting 'Finish'.
If I miss inferring a table, Radzen removes the associated code, breaking the app and raises an error for the missing component(s). Unfortunately, this is not reversable within Radzen so you have to infer the schema again with all the correct tables then redo the broken pages.
Due to the agressively proactive code building in Radzen, simple mistakes can lead to significant re-work.
1 Like
I'm working on the best way to get around the stored procedure nulls problem, which I'd written about yesterday. Rather than create the null variables in page properties (as the other suggestion doesn't work), I thought I'd alter the stored procedure and add null as the default parameters - seems cleaner. (more about default nulls in SP's later)
So, I thought that now that my SP is changed, I should infer it again in Radzen - hopefully it would see the default nulls and work without me having to supply null params. I opened the data source for edit, but now have a decision. Should I infer the tables, relationships and views also? They are already part of the project, so I'd think 'no' and unselect them. On the next page I verify that gen pages for crud is not selected, and overwrite is not selected. I select my SP and click finish and get an error. Error says something about a button pointing to something that doesn't exist. I go back to my project and every single page is destroyed. Full day of work down the drain.
So, I restore my project from yesterday's backup to try again. This time on the first page of the edit data source I make sure that everything is inferred - tables, relationships, views and stored procedures. On the next page I make sure that generate crud and overwrite existing is not selected, and then in entities unselect tables and views (again why select them again, they're already in my project) and make sure that only stored procedures are selected. Click finish, and boom. Get the error again, and my project is destroyed.
3rd try, I got it correct. On the first page of infer settings you have to make sure that everything is selected, and after inferring you then have to make sure that the entities are selected again - just make sure that generate crud and overwrite are off.
I'm not saying you have a bug here, but I think the process of updating your DB schema is absolutely anti-intuitive. I pretty much screw this up every time I attempt it - you'd think I'd learn but the process is so opposite of how I'd think it would work...
So, my suggestion would be to put some verbiage in the designer itself - and I'm not sure how you would do that. If that's not doable, then perhaps you could at least add something to your online documentation about the correct procedure to update the schema?
Thanks for listening,
Stephen
Use source control. Commit often. Push to your repository after every commit. Never lose any progress again. GitHub currently offers private repositories in their free plan.
The correct procedure to sync your Radzen application with the database changes is to do the minimal thing - just click the Infer schema button and then Finish. The Generate pages for CRUD operations is always unchecked by default. You don't have to ensure that. The same goes with Overwrite existing pages.
When you uncheck something it means "I don't want this in my Radzen application".
So no, there is no bug there and things work as intended. If you remove things that were inferred and pages generated for them your application will not compile.
1 Like
Okay korchev, thanks
Just revisiting this one. I inferred again to include two new columns in a view I had added at database side and this time Radzen decided to rename one of my most used tables. It renamed from to just . This of course broke everything and no I'm having to roll back to the last subversion commit 
Wht doesn't Radzen keep aconsistent naming convention?