ah now i get what the mapper actually does. ^^

Thanks

I think that you misunderstand what these connections are for.  They are not tied or associated with the BO in any way, shape, or form.  They are definiltey not needed at the customer site.  These connection string are ONLY used when trying to pull a schema to build the strong-typed properties for a BO...period.  These are are only used while you are mapping and nothing else.  The connection strings used for connecting to data are set through the DataSources and generally set in the AppMain.vb or program.cs files in the SetDataSources method...or through the Connection String wizard.  You can refer to the help docs for more information there.

tehe, glad that was not what you were saying ^^

i understood, that in order to map to views, i need to select "SQL Server" as Datasource within the BOM, for the reasons you explained.

i think right now, my main question in regards to this is:

When i select "SQL Server" as source in the BOM, it will ask me for the connection details. I could off course just enter them, but then what will happen when i deploy the application at a customer, who has different connection details to his sql server.

i read the connection details from an xml file, and add it as datasource through the code.

NO!!!!! That is not what I am saying at all!!!!   I am saying that when you are mapping a BO to a view that the DDT, though it will deploy views just fine, doesn't regex out and parse all of the individual field names to which the BO would be getting mapped.  That is why, when mapping a BO through the BO Mapper to a view you have to pull the schema from a view already associated with a server.  So if you are using the DDT, deploy the view first, then map the BO to the view by pulling the schema from teh deployed SQL Server database.

umm, so what you are saying is that the BOM/BO's does/do not support views ?

if so, that comes kind of unexpected. from my perspective views & stored procedures are common practice in working with sql databases.

No...we don't actually support this becuase we did not want to have to create a Regex sophisticated enough to match what the view produces.  So when mapping to a view, you will have to pull it from a SQL Server structure.  I can't say for sure if we will try and tackle this in the future, but it is done so little that this is the approach that we use internally and it works fine so it has never prompted us to invest the time and energy.

Hi,

thanks, this gives me an idea of the saving.

could you provide a pointer towards "enabling views" in the ddt requiring to select SQL Server instead of DDT, asof:

Thanks !

Well, first of all, data retrieval and updates are not connected.  So however you retrieve data into the BO is not connected to how it is saved.  So you could use a sproc, view, or manually populate the BO through XML data, etc. and the BO doesn't care where the data is coming from.

So the issue here isn't the data retrieval, but the saving.  At this point, you would just ensure that all expected columns in the BO exist prior to the save (i.e. if your data retrieval will exclude certain fields, then you will need to set the FieldsToExcludeInUpdate/Insert on the BO).  At this point, you can then update the CRUD settings of the BO to call the desired stored procedure.

If you are really trying to do something crazy on the save, then just override the Save method of that BO and take the contents and supply the information manually to the sproc in question and create an SqlCommand (or whatever database you are using) and then call an ExecuteNonQuery.  There are a lot of ways to go about this....but this should at least give you some ideas.

kind of a self bump here. would really appreciate a step-through example of my scenario above by someone from microfour.

additionally, since i need to select "SQL Server" and not "DDT" in the BOM to map views, it requires me to enter the connection details there. i was hoping it would rather get that from the datasource i set up in code, since off course the connection details on my workplace are not the same as at the client, and i am not sure where the deployed programm would try to pull it from.

i am reading theese from an xml file at runtime and adding the datasource in the code.

Hi Philipp,

I don't use DDT, and I can see all the views in the schema in the BO mapper. probably a side effect af DDT, let's wait for SF gurus answer.

The logic I use (and run) is:

1. Map the BO to view in the BO mapper
   
2. Fill BO using a FillDataTable(loCmdSQL).
   In the BO base class, I've a FillDataAllFields, and a FillDataAllFieldsOrderBy, and in each BO all the specifics FillDataTable methods required for these data.
   
3. Saving by stored procedure, called from the BO by an ExecuteNonQuery, or an ExecuteScalar on a function when I need to retrieve a result from the server (# lines really saved, intermediate results returned by triggers, etc..).
   Most often, I override the BO save method, so the business logic is in the save method, and the SP on the server manages data saving and referential integrity.