AS400

[Brad Allison]

Okay, I know I asked this before and I have just returned from the .NET
conference held by Verio in Boca Raton and I have a question. Before I had
asked if there was a data adapter for the AS400. Somebody responded by
letting me know that DTS worked fine. From what I understand, DTS is a part
of SQL Server, correct? If so, then my question becomes, what do I do if we
do not have SQL server? And if there is something to dynamically adapt to
the AS400, what would the pros/cons be of using something native from .NET
to the AS400 as opposed to getting SQL Server, doing a replication once a
day, using the message queue to download updated data once a day, etc?

Thanks for any information.

Brad Allison

 

[William \(Bill\) Vaughn]

For what it's worth, I have heard of companies buying a SQL Server license
and just using DTS with their data transformation tasks.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

 

[Bart Lynn]

Hit Software makes an .Net driver for the AS400.

http://www.hitsw.com/products_services/sql400/sql400.html

Bart

 

[Russell]

Although a license would be required for a production system, MSDE
(Microsoft Desktop -or is it Data?- Engine) also supports any DTS
Services if you can expose them. For testing and developement I used
MSDE and a copy of Enterprise Manager from a 120 day SQL Server CD.

Anything done by DTS can also be done through custom code (without SQL
Server)since it must use the same data access methods(OLEDB or ODBC
are your choices more or less).

I'm not sure what AS400 supports but between the ADO.net
oledbConnection and ODBCConnection, there should be something to
connect. If someone just wants a button on an intranet web page to do
simple table to table transfer on demand, custom code should be fairly
minimal. Simple schedules aren't too bad either (i.e. every 24 hrs).
Building a custom app may or may not be more cost effective then
buying an SQL Server License, depending on the amount of 'massaging'
done to the data during transfer.

DTS allows you to do very complex tasks very easily (update the a
column on all rows in SQL Server based on 'parellel' data column in X
data source) through a GUI. Scheduling of updates is also available
which is very handy and allows you to run updates as a service (no
user attention required), which is a BIG bonus. Error alerts can be
hooked into event logs or emails.

I would stay away from queues when working with replication. Message
Queuing is only necessary when the receiver of the data may not be
available in a timely fashion. If the receiver is not available, the
message is held or other steps are taken. Message queues should only
be used as a last resort for transactional based systems that both
sides of the transaction participate in (you send me a request, I
verify your request, I send you a bill, you send me payment
verification).

things to consider:
- How fresh do I need to keep my data
- How much data is being transfered (network traffic)
- How long will it take (less then 5 minutes? or three hours)
- Will the transfer affect other users (lock out tables or rows that
they need)
- What happens if the transfer fails (does a batch process require
the fresh data?) -- this is a big one. IF it fails, will everyone have
to wait around for YOU to fix it? Try to avoid this bottleneck

Hope that helps