MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » October 2012

RE: replicating an I-series home-grown application to a .net platform



fixed

A less secure server? How did you make that assumption. Apparently you are not well versed in the *PUBLIC issue that a lot of as400 shops face when they have a security audit. Read this article to bring yourself up to speed, specifically the section "Current state of i Security - The default is insufficient": http://www.iprodeveloper.com/content1/print?topic=db2-data-protection-options-and-essentials-62310&catpath=security&print=1

In MS SQL they didn't make this mistake, the default is no permissions by default. A lot of this insecurity mantra that is still perpetuated to this day comes from Windows 2000 and prior OS's.

From what I've seen at our shop, the current IBM i database doesn't lend itself to an ORM solution very well because the database was poorly designed to begin with because they were built so long ago before database theory evolved to the state it is today.

A lot of shortcuts were made to make the data easy to access using CHAIN and other non-SQL commands in RPG. This has led to non-normalized database structure that is fraught with problems as a result. For ORM's to be usable which is what the original request was about doing, you really need a well-designed (normalized) database.

The IBM i DB2 can be a perfect solution for an ORM using nHibernate (we use this) and Entity Framework (however you need to get a driver from DataDirect which costs $$$ which is why we went with nHibernate, may be the reason why you are trying replicate the data) without the need to do data replication to a SQL Server.


-----Original Message-----
From: Chris Bipes [mailto:chris.bipes@xxxxxxxxxxxxxxx]
Sent: Friday, October 05, 2012 10:39 AM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: RE: replicating an I-series home-grown application to a .net platform

But with the IBM iSeries Access OBDC drivers on the .NET application server, you can pull the data directly off of the iSeries. No copying of your data to a less secure server. But not being a .NET programmer, can you attach to a remote DB server or does the DB server have to run on the same box as the application server? (Really a bad idea if being opened to the internet.)

--
Chris Bipes
Director of Information Services
CrossCheck, Inc.
-----Original Message-----

1. It is worthwhile and here's why. The best model for accessing db in .net, especially c# is with an ORM tool like Linq to sql. Using linq to sql if foreign keys are mapped, then you can simply traverse the chain.

For instance the one to many relationship of product categories to products can be expressed in code as

myDataContext db = new myDataContext();
foreach (product myprod in db.products.Where(p=>p.name.StartsWith("Sample"))
{
Console.WriteLine("My Product Name: {0}", myprod.name);
Console.WriteLine("My Product Category Name: {0}", myprod.category.name); }

In the last line you can see the foreign key relationship is automatically followed and referenced making code super clean. It's worthwhile.

2. Yes. We use data queues. Data queues are without a doubt the BEST way to do this. Another good way might be to use a journal receiver or trigger to push the data to the sql server but we prefer to poll and pull from the i.

And if anyone knocks you for copying data over to a sql server, just show them that code snippet and ask them if it's understandable and maintainable vs rpg ... lol

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.






Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact