Need some advice - Developing Integration Module

Hello All,

I need some advice on how to proceed. First off some background. I
work as a Sales Engineer for a Software Company that has developed a
product to monitor VoIP passively. They have asked me to develop a
Integration Module for a product from a company that I previously
worked for. Lets call my current companies product A and my previous
companies software B. What I proposed was that from B we perform a DBI
connection, via a Perl script, into A to gather the data to import
into B. God I hope I am making sense! This would be the most efficient
way to import the data into B. Otherwise we would need to remote over
to A from B execute the sql queries and spit the data out into flat
files for B to ftp over to itself then import. Yuk!

So here is the question, Company A is concerned that if we perform the
SQL commands from B then we would be eliminating our Value Add and
opening up our DB and loose the control. Is this true?

I don't see where they are coming from, I have been working with NMS
type software for 10 years and exporting of data is by no means a
taboo act.

What's your opinions?

Thanks again,

Joe

joseph.madi@gmail.com wrote:
> Hello All,
>
> I need some advice on how to proceed. First off some background. I
> work as a Sales Engineer for a Software Company that has developed a
> product to monitor VoIP passively. They have asked me to develop a
> Integration Module for a product from a company that I previously
> worked for. Lets call my current companies product A and my previous
> companies software B. What I proposed was that from B we perform a DBI
> connection, via a Perl script, into A to gather the data to import
> into B. God I hope I am making sense! This would be the most efficient
> way to import the data into B. Otherwise we would need to remote over
> to A from B execute the sql queries and spit the data out into flat
> files for B to ftp over to itself then import. Yuk!
>
> So here is the question, Company A is concerned that if we perform the
> SQL commands from B then we would be eliminating our Value Add and
> opening up our DB and loose the control. Is this true?
>
> I don't see where they are coming from, I have been working with NMS
> type software for 10 years and exporting of data is by no means a
> taboo act.
>
> What's your opinions?
Well "companies" shoule be "company's" for a start!

>
> Thanks again,
>
> Joe

Paul Lautman wrote:
> Well "companies" shoule be "company's" for a start!
>
And shoule should be should!

On Jan 29, 3:05 pm, "Paul Lautman" <paul.laut...@btinternet.com>
wrote:
> Paul Lautman wrote:
> > Well "companies" shoule be "company's" for a start!
>
> And shoule should be should!

Well you are off to a great start correcting my grammar. Any relevant
insight to my situation?

To all of you that have sent me direct responses, thank you so much
for your attention and assistance.

Joe wrote:
> On Jan 29, 3:05 pm, "Paul Lautman" <paul.laut...@btinternet.com>
> wrote:
>> Paul Lautman wrote:
>>> Well "companies" shoule be "company's" for a start!
>> And shoule should be should!
>
> Well you are off to a great start correcting my grammar. Any relevant
> insight to my situation?

You need access to a system full of data the company doesn't
want to give access to.
Your problem is not a technical one.

To solve it, you came up with several wildly complex file
transfer strategies - none of which will get around the access
problem.

You've got a problem with no solution, and a solution with no
problem.
And you posted both as an off-topic message in a technical group.

What did you expect?

On Jan 30, 12:55 pm, Sanders Kaufman <b...@kaufman.net> wrote:
> Joe wrote:
> > On Jan 29, 3:05 pm, "Paul Lautman" <paul.laut...@btinternet.com>
> > wrote:
> >> Paul Lautman wrote:
> >>> Well "companies" shoule be "company's" for a start!
> >> And shoule should be should!
>
> > Well you are off to a great start correcting my grammar. Any relevant
> > insight to my situation?
>
> You need access to a system full of data the company doesn't
> want to give access to.
> Your problem is not a technical one.
>
> To solve it, you came up with several wildly complex file
> transfer strategies - none of which will get around the access
> problem.
>
> You've got a problem with no solution, and a solution with no
> problem.
> And you posted both as an off-topic message in a technical group.
>
> What did you expect?

Thank you for your response. I intended to ask professional developers
who were accustomed to working for major/minor software companies of
their experience dealing with this sort of issue. I disagree that even
though my question did not request help with a sql statement, it was a
technical one in that, was the DBI solution not a proper interface for
capturing data. I have received advice from people working for HP, CA,
SUN and others. So my post was taken with professional courtesy as I
had hoped.

Again thank you for your opinion andI hope that you do not feel that
technical forums are restricted to only programming help, but rather a
community of professionals, in this case MySQL experts and novices
that can seek advice directly from each other.

Take care,