|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
+x+x+x+x+x+x+xi recently updated my projects to VS2022 and the Strataframe "process" that goes along with it. I apologize, in advance, if this gets a little wordy...but I want to explain where I am at. i have an issue in my most recent project (~2018). A BO is no longer saving using the _Insert and _Update procedures... The error: "Procedure or function 'AlternatePosition_Insert' expects parameter '@ap_UsePrimaryJobTitle', which was not supplied."In theory, that would point to a disconnect between the DDT and the BOM, right? I add the screen snip below to point out that 4 items are not updating/inserting properly. They just happen to be 4 columns that I added after the table's creation.  Anyway, prior to the conversion to 2022, this BO saved fine. And the DDT did its job...  With Larry retired, I am not as well versed in the inner machinations of Strataframe... For instance, I wouldn't know where to look in SF to check that fields are missing from an _Insert or _Update call. When I look in the BOM, i see the full table... but a rebuild doesn't correct the problem.  And, I have never had this issue in SF before. And I've saved many BOs without incident since 2008. So... the fact that FOUR parameters were not being added... and the proximity to the update/upgrade made me wonder. If this is a known issue and I'm just sleeping on it... I apologize. I'm just stuck right now. Again, I apologize for the wordy post (hey, i did add pictures too!). Any help you could provide me would be appreciated. Thanks, Sean Santa Cruz County, CA I enjoyed your post, the comments at the bottom regarding the pictures made me laugh. I know that knowing the inner workings of something can make a huge difference. The good news here is that updating to VS2022 didn't create the issue. We've been on VS2022 for years and this in and of itself doesn't affect how the code works in relation to a BO. A BO uses the mapped schema to fill out the required fields. If you open up the Designer file of the BO, and go down to the CreateTableSchema method, it will show all of the columns that the BO knows about. This gets created when you map a BO through the BO Mapper. So before you rebuild the partial class, look and see if you have all of the fields that are appearing. It seems to me like your BO and the SPROC are not lining up. If they are not in the partial class of the BO, then it will not know to fill them out.  (I thought I would add a pretty image too). Hi Trent, Sean, Well, even though I love having pictures in my messages, but, I am loving more right now seeing this thread in the forum. I may be wrong, but if I remember correctly, switching to VS2022 also required an updated Extensibility extension and an updated DDT as well. Because Sean simply added 4 new columns to this table in the DDT, the DDT is the one responsible for automatically creating these system stored procedures and there may be something failing in that process. It could also be that the BO was not regenerated from the BOM (Business Object Mapper) then the columns are not in the designer as explained by Trent. Best! Thanks Edhy! It's like the SF all-stars helping me out... 8^ ) I'll attach Larry's doc if needed. It is a lengthy list of steps... Shawn, Did you regenerate the BO from the BOM? yes... if you mean Rebuild And i should add... that Larry had me run the DDT outside of VS... as a separate program/icon in my Start Menu... And that the BOM is run from VS... Extensions -> Strataframe -> BOM Yes, that is correct. Do you CRUD settings look something like this:  This indicates that the BO will determine the name of the SPROC used. Second, are you including all of the fields in the query to populate this BO? It will enumerate the DataTable columns like the code below. So if you run a query to populate the BO and then don't include all of the columns then try to save, it will create this same issue. Here is how it determines which columns will be included in the SPROC update process: For Each loColumn In UpdatingTable.Columns
'-- Logic here to build SPROC columns
Next
One thing you can do is put a debug where you are saving before it actually calls the save itself. Look at the CurrentDataTable property in the VS debug viewer and see what columns are there. I bet they are missing the new ones, but the Update SPROC is expecting them.
|
|
Group: StrataFrame Users
Posts: 6,
Visits: 61
|
+x+x+x+x+x+x+x+xi recently updated my projects to VS2022 and the Strataframe "process" that goes along with it. I apologize, in advance, if this gets a little wordy...but I want to explain where I am at. i have an issue in my most recent project (~2018). A BO is no longer saving using the _Insert and _Update procedures... The error: "Procedure or function 'AlternatePosition_Insert' expects parameter '@ap_UsePrimaryJobTitle', which was not supplied."In theory, that would point to a disconnect between the DDT and the BOM, right? I add the screen snip below to point out that 4 items are not updating/inserting properly. They just happen to be 4 columns that I added after the table's creation. Anyway, prior to the conversion to 2022, this BO saved fine. And the DDT did its job... With Larry retired, I am not as well versed in the inner machinations of Strataframe... For instance, I wouldn't know where to look in SF to check that fields are missing from an _Insert or _Update call. When I look in the BOM, i see the full table... but a rebuild doesn't correct the problem. And, I have never had this issue in SF before. And I've saved many BOs without incident since 2008. So... the fact that FOUR parameters were not being added... and the proximity to the update/upgrade made me wonder. If this is a known issue and I'm just sleeping on it... I apologize. I'm just stuck right now. Again, I apologize for the wordy post (hey, i did add pictures too!). Any help you could provide me would be appreciated. Thanks, Sean Santa Cruz County, CA I enjoyed your post, the comments at the bottom regarding the pictures made me laugh. I know that knowing the inner workings of something can make a huge difference. The good news here is that updating to VS2022 didn't create the issue. We've been on VS2022 for years and this in and of itself doesn't affect how the code works in relation to a BO. A BO uses the mapped schema to fill out the required fields. If you open up the Designer file of the BO, and go down to the CreateTableSchema method, it will show all of the columns that the BO knows about. This gets created when you map a BO through the BO Mapper. So before you rebuild the partial class, look and see if you have all of the fields that are appearing. It seems to me like your BO and the SPROC are not lining up. If they are not in the partial class of the BO, then it will not know to fill them out. (I thought I would add a pretty image too). Hi Trent, Sean, Well, even though I love having pictures in my messages, but, I am loving more right now seeing this thread in the forum. I may be wrong, but if I remember correctly, switching to VS2022 also required an updated Extensibility extension and an updated DDT as well. Because Sean simply added 4 new columns to this table in the DDT, the DDT is the one responsible for automatically creating these system stored procedures and there may be something failing in that process. It could also be that the BO was not regenerated from the BOM (Business Object Mapper) then the columns are not in the designer as explained by Trent. Best! Thanks Edhy! It's like the SF all-stars helping me out... 8^ ) I'll attach Larry's doc if needed. It is a lengthy list of steps... Shawn, Did you regenerate the BO from the BOM? yes... if you mean Rebuild And i should add... that Larry had me run the DDT outside of VS... as a separate program/icon in my Start Menu... And that the BOM is run from VS... Extensions -> Strataframe -> BOM Yes, that is correct. Do you CRUD settings look something like this: This indicates that the BO will determine the name of the SPROC used. Second, are you including all of the fields in the query to populate this BO? It will enumerate the DataTable columns like the code below. So if you run a query to populate the BO and then don't include all of the columns then try to save, it will create this same issue. Here is how it determines which columns will be included in the SPROC update process: For Each loColumn In UpdatingTable.Columns
'-- Logic here to build SPROC columns
Next
One thing you can do is put a debug where you are saving before it actually calls the save itself. Look at the CurrentDataTable property in the VS debug viewer and see what columns are there. I bet they are missing the new ones, but the Update SPROC is expecting them. Wow. It's both embarrassing AND a relief. Thank you both for helping me. I'm pretty maniacal about updating the SPROCs, but in this case, i must not have updated the DDT. AND, that little issue didn't rear it's ugly head until I needed to run the DDT - which must have coincided with the upgrade. Ah geez fellas. I'm not a rookie, but I made a rookie mistake. I'll update my Strataframe Wiki to make sure it doesn't happen again. Thanks again both of you.
|
|
Group: StrataFrame Developers
Posts: 6.6K,
Visits: 6.9K
|
+x+x+x+x+x+x+x+x+xi recently updated my projects to VS2022 and the Strataframe "process" that goes along with it. I apologize, in advance, if this gets a little wordy...but I want to explain where I am at. i have an issue in my most recent project (~2018). A BO is no longer saving using the _Insert and _Update procedures... The error: "Procedure or function 'AlternatePosition_Insert' expects parameter '@ap_UsePrimaryJobTitle', which was not supplied."In theory, that would point to a disconnect between the DDT and the BOM, right? I add the screen snip below to point out that 4 items are not updating/inserting properly. They just happen to be 4 columns that I added after the table's creation. Anyway, prior to the conversion to 2022, this BO saved fine. And the DDT did its job... With Larry retired, I am not as well versed in the inner machinations of Strataframe... For instance, I wouldn't know where to look in SF to check that fields are missing from an _Insert or _Update call. When I look in the BOM, i see the full table... but a rebuild doesn't correct the problem. And, I have never had this issue in SF before. And I've saved many BOs without incident since 2008. So... the fact that FOUR parameters were not being added... and the proximity to the update/upgrade made me wonder. If this is a known issue and I'm just sleeping on it... I apologize. I'm just stuck right now. Again, I apologize for the wordy post (hey, i did add pictures too!). Any help you could provide me would be appreciated. Thanks, Sean Santa Cruz County, CA I enjoyed your post, the comments at the bottom regarding the pictures made me laugh. I know that knowing the inner workings of something can make a huge difference. The good news here is that updating to VS2022 didn't create the issue. We've been on VS2022 for years and this in and of itself doesn't affect how the code works in relation to a BO. A BO uses the mapped schema to fill out the required fields. If you open up the Designer file of the BO, and go down to the CreateTableSchema method, it will show all of the columns that the BO knows about. This gets created when you map a BO through the BO Mapper. So before you rebuild the partial class, look and see if you have all of the fields that are appearing. It seems to me like your BO and the SPROC are not lining up. If they are not in the partial class of the BO, then it will not know to fill them out. (I thought I would add a pretty image too). Hi Trent, Sean, Well, even though I love having pictures in my messages, but, I am loving more right now seeing this thread in the forum. I may be wrong, but if I remember correctly, switching to VS2022 also required an updated Extensibility extension and an updated DDT as well. Because Sean simply added 4 new columns to this table in the DDT, the DDT is the one responsible for automatically creating these system stored procedures and there may be something failing in that process. It could also be that the BO was not regenerated from the BOM (Business Object Mapper) then the columns are not in the designer as explained by Trent. Best! Thanks Edhy! It's like the SF all-stars helping me out... 8^ ) I'll attach Larry's doc if needed. It is a lengthy list of steps... Shawn, Did you regenerate the BO from the BOM? yes... if you mean Rebuild And i should add... that Larry had me run the DDT outside of VS... as a separate program/icon in my Start Menu... And that the BOM is run from VS... Extensions -> Strataframe -> BOM Yes, that is correct. Do you CRUD settings look something like this: This indicates that the BO will determine the name of the SPROC used. Second, are you including all of the fields in the query to populate this BO? It will enumerate the DataTable columns like the code below. So if you run a query to populate the BO and then don't include all of the columns then try to save, it will create this same issue. Here is how it determines which columns will be included in the SPROC update process: For Each loColumn In UpdatingTable.Columns
'-- Logic here to build SPROC columns
Next
One thing you can do is put a debug where you are saving before it actually calls the save itself. Look at the CurrentDataTable property in the VS debug viewer and see what columns are there. I bet they are missing the new ones, but the Update SPROC is expecting them. Wow. It's both embarrassing AND a relief. Thank you both for helping me. I'm pretty maniacal about updating the SPROCs, but in this case, i must not have updated the DDT. AND, that little issue didn't rear it's ugly head until I needed to run the DDT - which must have coincided with the upgrade. Ah geez fellas. I'm not a rookie, but I made a rookie mistake. I'll update my Strataframe Wiki to make sure it doesn't happen again. Thanks again both of you. LOL...I am 30+ years in and I just made a rookie mistake 10 minutes ago...so no judgement here!! Glad you got it figured out.
|