I have been given a project to create HL7 Continuity of Care Documents (CCD) using data stored in a SQL Server 2008 database. I have intermediate to advanced knowledge in SQL programming but I have never used FOR XML statements.
Has anybody ever built a stored procedure that would successfully create CCD's strictly using only SQL programming with FOR XML?
Any tips would be greatly appreciated. If anybody used anything else besides SQL, feel free to let me know, but my background is mainly in SQL, T-SQL, with some knowledge in Java and VB.
Thanks
The way that we approached this issue in our .Net application is that we first created classes from the CCD or CDA xsd (which can be obtained from several locations, including the HL7 store) using Microsoft's xsd tool.
We then wrote (a lot of) code that creates and populates the CCD classes from data in the database.
In order to present the data to the user, we first serialized the record to string using the XMLSerializer, then converted the generated XML to HTML using the ccd.xsl transform file. There are several locations for the ccd.xsl including this one.
Related
I would like to know if anyone has a good solution for importing BAIv2 banking files into SQL Server. First of all the files have "continuation records" which have to be considered along with the parent records. Also, T-SQL doesn't have a pleasant way of parsing comma-separated strings. Finally, one hierarchy in the file has a varying number of elements so that makes direct pasting into a table difficult because the columns would not line up.
This is the file from hell. If anyone has any insights into how to import and parse BAIv2 banking files I would be most appreciative.
Thank you,
You're best off handling this with a dedicated application server and a real (general-purpose) programming language. T-SQL is ill-suited for this task.
When that's not an option, you can use C# for a SQL CLR stored procedure to parse the files. I did something similar for banking flat-files when I didn't have the option of an application server.
Is using strongly typed dataset is good.
Currently I am working on a project developed using VB.Net in Visual Studio 2010.
Previously they were using Sql queries directly into SqlCommand of System.Data.SqlClient, but then after i shifted everything to Strongly Typed DataSet and started using TableAdapters every where..
Now i just wanna ask that is this way is good for a project...
Or Should i shift back to old ones using Just SqlCommands
Or Is there any way to make Sql DataBase in a good way because its an ERP and most of the code is for Data Access..
We use strongly typed datasets all the time now.
After shifting to this behaviour it felt really bad to have SQL-querys in code instead of having it done by the table adapter. But there is a bit overhead with datasets so I guess booth ways are good for different solutions.
Its really nice to have intellisence on all fieldnames and if you change a tableadapter so it returns something different you get design-time errors everywhere where you need to change the code to reflect the change, instead of finding out runtime when the customer is running the program.
There are so many win win-things with strongly typed datasets so I'll never go back.
Table adapters .... make a lot of mess with bigger databases, also updating the table structure also causes confusion.
I would recommend to use some auto code generators for the CRUD Operations.
To me your old pattern looks better than switching altogether to table adapters and strongly typed datasets.
If you ever want to move your data across the wire to other platforms (silverlight, web services, wcf services, etc), then using any kind of dataset will box you into a corner.
The way that we have resolved this is to have classes whose list of properties match the database exactly. To move the data in and out of the database, we use reflection to either match stored procedure parameters or generate dynamic SQL statements, depending on the circumstance and platform.
When a database table is changed, the developer making the change is also responsible for updating the class structure and vice-versa.
In order to reduce the amount of hand-coding required, we use the code generation capabilities of CodeSmith to generate classes from the database and create the basic implementations of our standard add/update stored procedures that require field enumeration.
As an added benefit, this approach removes the tight link between the database and business object structure. We are able to use our same data access code and business object classes against SQL Server, Oracle, Sqlite, and SqlServerCE databases. This code is used to create applications in Windows, PocketPC, Web, iPad, and Android apps; all of the mobile apps use local databases specific to the platform, but using the common data access code.
It is a bit more work to setup initially, but it will pay significant dividends in the long run.
I am a developer for a global application, which was deployed in a few countries whose languages were not a problem for us. But now, we're going to Slovakia, and we're having a bit of trouble with EclipseLink.
We've setup a small web application to test the text encoding on the database for their project. We're able to read data using EclipseLink, which was inserted directly on the database (SQL server), but when trying to insert using the EntityManager, EclipseLink sends a bunch of unicode chars instead, which are not 'translated' by the database, but inserted as is.
I'm kinda clueless so far, since I've tried to search on EclipseLink for documentation regarding this topic, but had no luck. Can you guys share some of your wisdom regarding this? Anyone had to support other languages using ORM frameworks, and can share their experience?
Thanks in advance!
As it turns out, the issue is dealt with at the DBMS level. The tables that contain textual data need an appropriate type in order to handle unicode characters; in the case of SQL server, this type is 'nvarchar'.
I’m interested in knowing some different approaches for retrieving data from Analysis Services, to use in either objects in code, or for end-user reporting.
I’ve used two different approaches in the past, one was using ADOMD to pull results and put these into a dataset, the other was using SQL OPENQUERY to a linked SSAS server to get results out as a SQL stored procedure result set. Both of these had advantages and disadvantages.
Over the years I’ve seen various questions along this line, so forgive me for any duplication, but what other methods are there for getting SSAS data into a format where other people’s code could use it?
I’ve considered XML result sets from SSAS over HTTP, then Linq to XML – Anyone have any experience with that?
Ideally I’d like a dataset with typed columns, or objects with properties, but I’m more interested in general approach than code samples. How have you got data from SSAS, apart from SSRS/Other dashboard controls?
I know MS is supposed to support XML/A (XML for Analysis). I am shortly releasing an ajax library to do XML/A requests from web pages.
While I am currently focused on Pentaho's Mondrian, it should work for MS SQLs XML/A too. If you are interested, I am doing a presentation on it on January 13. (see: http://wiki.pentaho.com/display/COM/January+13,+2010+-+Roland+Bouman+-+OLAP+and+Analysis+for+web+applications+using+XMLA) I will be releasing my code by that time too (probably underr a LGPL license)
I would love to get feedback from people that use other XML/A servers, so if you are interestd, it would be great to work together on this.
UPDATE:
the project is now available at http://code.google.com/p/xmla4js/ There is API documentation, code samples, and build scripts. It's LGPL so you're free to use it in your applications, even for commercial purposes. The license does require that you release any modifications to the library itself as LGPL (but this does not affect the application that uses the library)
UPDATE2
The project no resides on github at https://github.com/rpbouman/xmla4js
It works in the browser as well as in nodejs.
I've never used it myself, as we only use ADOMD and Excel to connect to SSAS, but at some point we considered using HTTP and XML. We ended up going the ADOMD route because of a shortened dev schedule, but I guess it's another option that allows for access to SSAS outside of the .Net world.
Here's a link which I found useful when prototyping: Configuring HTTP Access to SQL Server 2008 Analysis Services on Microsoft Windows Server 2008
XMLA is the "high power" approach -- but I'm not aware of a toolkit or library that really exposes the full capabilities of XMLA; I think you would have craft it up yourself. For the projects I've done, that's just way too much work.
Instead, I used ADOMD.NET for retrieving results in code; the CellSet class in particular is fairly rich. For end user analysis (slice and dice), most often I use Excel Pivot Charts (which are fabulous!); sometimes I also use Visio Pivot Diagrams. For fixed reporting, Reporting Services can access SSAS directly, and it even has it's own query builder.
BTW, in case it helps, I have a chapter in my book about integrating SSAS with web sites as a way of offloading SQL Server: Ultra-Fast ASP.NET. My code examples use ADOMD; I also walk through building a simple cube, configuring automatic updates with SSIS, using proactive caching, building simple MDX queries, etc.
Another approach is to use the MSOLAP OLE DB provider. Our code is currently using this method.
Another way (and I would say the simplest one) to get data from SSAS OLAP cubes into .NET is by using LINQ + ADO.NET Entity Framework + SSAS Entity Framework Provider .
(I work for the company that developed SSAS Entity Framework Provider).
I am looking for information on the best practices or project layout for software that uses SQL embedded inside VB.NET or C#. The software will connect to a full SQL DB. The software was written in VB6 and ported to VB.NET, we want to update it to use .NET functionality but I am not sure where to start with my research. We are using Visual Studio 2005. All database manipulations are done from VB.
Update: To clarify. We are currently using SqlConnection, SqlDataAdapter, SqlDataReader to connect to the database. What I mean by embed is that the SQL stored procedures are scripted inside our VB code and then run on the db. All of our tables, stored procs, views, etc are all manipulated in the VB code. The layout of our code is quite messy. I am looking for a better architecture or pattern that we can use to organize our code.
Can you recommend any books, webpages, topics that I can google, etc to help me better understand the best way for us to do this.
I am looking for a better architecture or pattern that we can use to organize our code
...
topics that I can google
Take a look at DAL (Data Access Layer) for database transactions
Here is a link to a StackOverflow question posted by someone who is facing a similar situation
Creating a Class Library in VB.NET
When you google "How to create DAL", you will see list of how to create a DAL as well as what DAL is.
And here is a nice article that shows how DAL fits into an N-Tier achitecture
What is n-Tier Architecture?
Webopedia: N-Tier Application Architecture - Shows a nice graphical representation
It sounds like you're looking for a grand theoretical book that is written for one very specific case, i.e. what is the best practice for managing our current spaghetti SQL code framework, and I don't know that I've ever seen a book or document that describes that.
That being said, we converted several applications from VB6 to C# a few years back and were in the same place. Other than breaking apart certain modules so that their organization made more logical sense overall, our applications are essentially the same as they were, just rewritten in C#. I don't personally like the idea of separating SQL code from the function for which it was written (which is sort of what it sounds like you're trying to do); in general, if we have a function that needs to hit the database, we create a SqlCommand and, optionally, a SqlDataReader, set the CommandType to StoredProcedure and add the parameters, then perform the call and consume the result, doing with it whatever the function was programmed to do.
I don't know that that is the best way to do it, but it works for us.
Would it be possible to convert it to using LINQ? It's safer than converting it to using regular old embedded SQL statements.
In addition to what Sung Meister said, you should also consider moving the SQL from the VB.NET code into Stored Procedures, and then call the SPs from the VB.NET code (the Data Access Layer). It provides many advantages.