Hi,

We just created an image file, 6 megs of data. There are 2 issues here:

<del>1: After loading the image, quadrant doesn't show the data in it.
There is 1 error (some FK error) during load, does this disrupt everything? Can i ignore these errors while loading data?</del>

Using -force


2: exporting the image, results in an image file; we need an xml structure of the data that is exported. Can i export XML from .mx files?
(or; do we need to define a language and then run mgx?). Currently i can only get .mx files; i couldn't find hints in the manuals to convert this into something else.

Link: http://msdn.microsoft.com/en-us/library/dd129631(VS.85).aspx

I see there was an excel integration tool? This is no longer shipped with "Oslo".
http://community.bartdesmet.net/blogs/bart/archive/2009/02/14/the-m-programming-language-part-0-intellipad-mrepl-vs2008-project-support-and-excel-integration.aspx


Regards,
Elger

This is a follow up on this story:
http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/7d20d607-dbbf-4924-9d33-372bfb78e276

---

Performing my Final Project, looking into codename "Oslo".

Elger,

I'll answer your questions as best as I understand them. Let me know if I'm missing your intent.

On your first question, I believe you're wondering how much tocode againstthe SQL details of your M model. In the end, I think using the SQL patterns such as folder and keys is unavoidable if you want to take advantage of these patterns when accessing the data via SQL. If these patterns aren't relevant for your scenario, then you might not need to dig into the details of how to use them on the SQL side. I think you're on the right track here. Looking at SQL documentation inMSDN makes sense. Since it's really a database, using general database best practices for data access seems appropriate, regardless of whether the data/schema is coming from M or another source. Again, this is part of the beauty of M; the need to learn new techniques and best practices for using a Repository is reduced since it's a database and standard database best practices can apply.

Regarding your second question, I agree that Quadrant should allow for browsing your data without writing custom code. For getting XML out of the database, you might try a FOR XML query in SQL Server (or any other technique you like, such as others mentioned in my previous post).

Regarding a schema for the XAML files, unfortunately I don't have any personal knowledge there (I don't know if there is any such schema). Someone else may have more information for you.

On your final question, yes, I suspect trying to use the .mx file directly to get an XML version of your data is likely to be more difficult thaninstalling the.mx file intoa databaseand using standard SQL->XML techniques from there.

I hope this helps. Let me know if I can clarify further.

David

Elger,

Just to clarify:
Are you starting with some database data ina Repository (or other database) and trying to produce XML? Or do you first have the data somewhere else (such as in "M")?

Also, are you looking for information on any available technologies for getting XML data out of the Oslo toolchain (more interested in technical possibilities, not neccessarily best practices), or are you trying to find an optimal approach for a particular situation?

David

Hi David,

We just want to get XML data out of the Oslo toolchain.

This XML will be transformed to our XML requirements using xslt. (at least, we think of it this way)


There seems no option to export XML in the May 2009 CTP.


Our proof of concept is the following:

Load data from XML to M (100% done).
Getting the M in the repository (95% done),
Viewing the data in Quadrant the way we like it (70% done),
getting the data from the repository to XML (0% done)

Essentially: we are replacing our data editing / modeling environment from "something else" to "Oslo" / Quadrant.
The output from "something else" was XML, that was tranformed to our XML needs.
"Oslo" should therefore also export XML for our in-house toolchain.

---

Performing my Final Project, looking into codename "Oslo".

The mx file is in zip format. Did you trychanging the file extensionto .zipand looking at it's content?

Dana

Elger,

If you're just looking to get XML out of the database:

Oslo provides (among other things) a great way to get custom text data into a standard database. However, Oslo isn’t a new data access layer for database data. Part of the beauty of the Oslo design is that once we get your data in the database, you can use any standard data access tool to process it. We bring custom text into the standard database world, allowing you to leverage the plethora of existing great data access tools. In other words, while there is an “Oslo�way to get custom text data into the database (using “M�, the “Oslo�way to get data out is whatever favorite data access tool you want to use: Entity Framework, LINQ to SQL, sqlcmd.exe, SSIS, ADO.NET, Excel, etc.

For your specific case, it sounds like you’re just trying to export some database data to XML. (Let me know if I’m misunderstanding your scenario.) If your data is already in the database, I’d recommend trying something like a FOR XML query, which is a fairly low-friction way to transform relational data into XML. Or you could read the data through the Entity Framework or LINQ to SQL and then write the data to XML using XDocument or XmlWriter. With Oslo, you really have full freedom in choose your favorite/most appropriate technology for database access (to read your data) and XML (to write your data).

The above answer applies for getting Repository (Databse) Data -> XML.

However, it's also important for us to have a good experience around getting data back and forth between M and XML. Design and implementation work for these features is ongoing. These features are particulary relevant when your data is in M and you want to produce XML directly, without going to a database in between (or, when your data is XML and you want to go directly to M).

If your data is in the database, going from Repository -> M -> XML is probably going to be more tricky than going directly fromRepository -> XML, unless other considerations require using M in the pipeline for some reason. (And our M <-> XML features today are limited.)

So I guess the answer is twofold. In general, if you want to go from Repository (relational data) -> XML, you can use the data access layer of your choice. For M data <-> XML data in particular, there is ongoing work to provide better functionality here.

Please let me know if this addresses your question. Thanks for your interest in Oslo!

David

The mx file is in zip format. Did you trychanging the file extensionto .zipand looking at it's content?

Dana

Now that's a protip :)

---

Performing my Final Project, looking into codename "Oslo".

Ok, this is sounds good.

To elaborate on the reason of our issue:

We model in M. This model is transformed to SQL conforming to Oslo design patterns. This means data is distributed in various schema's in the same database. It also means there are views on the data. There could be a number of design patterns going on, which might alter the structure of the repository; accessing the data with SQL directly might be more complex than Quadrant wants us to believe.

But it also makes perfect sense that Oslo is not intended as another database access layer; so accessing the data in the database should be as simple as viewing it with Quadrant. that means: Its a trivial task. But do we also want to read the things that happen under-water like folders and artificial keys? We choose not to, where another might say yes. (we might change our minds also from day to day). I guess we will be looking closely at the SQL design patterns in MSDN for this, is this correct?

I hope there are great ways to get the data out without writing 1 customline of SQL; just browsing, clicking and setting 1 or 2 filters is all we need (we need lots of related data from a particular record). Transformation to XML is probably covered by SQL. Whatfunctionality inwhat tool could assist us in doing this?



If we want to continue our tour on using XML:
We need to have a schema to understand what is happening in the mxExportedCompilationUnit.xaml. Has this schema already been published?


My question for now is: is utilizing the mx filethe difficult approach for data access compared to SQL? I think it is.


Some thread in the same direction: http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/576556d7-599c-411b-837f-a53d362455bb

---

Performing my Final Project, looking into codename "Oslo".

Elger,

I'll answer your questions as best as I understand them. Let me know if I'm missing your intent.

On your first question, I believe you're wondering how much tocode againstthe SQL details of your M model. In the end, I think using the SQL patterns such as folder and keys is unavoidable if you want to take advantage of these patterns when accessing the data via SQL. If these patterns aren't relevant for your scenario, then you might not need to dig into the details of how to use them on the SQL side. I think you're on the right track here. Looking at SQL documentation inMSDN makes sense. Since it's really a database, using general database best practices for data access seems appropriate, regardless of whether the data/schema is coming from M or another source. Again, this is part of the beauty of M; the need to learn new techniques and best practices for using a Repository is reduced since it's a database and standard database best practices can apply.

Regarding your second question, I agree that Quadrant should allow for browsing your data without writing custom code. For getting XML out of the database, you might try a FOR XML query in SQL Server (or any other technique you like, such as others mentioned in my previous post).

Regarding a schema for the XAML files, unfortunately I don't have any personal knowledge there (I don't know if there is any such schema). Someone else may have more information for you.

On your final question, yes, I suspect trying to use the .mx file directly to get an XML version of your data is likely to be more difficult thaninstalling the.mx file intoa databaseand using standard SQL->XML techniques from there.

I hope this helps. Let me know if I can clarify further.

David