Three options I'm aware of, if you're looking for SQL server/SSRS
reporting capabilities:
Convert your main database to SQL server. If you're already on Epicor
9.05, this requires a re-install of Epicor server software as well as
the database conversion.
Leave main database in Progress, and use replication server to copy to a
SQL server database for reporting etc. I believe the replicated data
runs about a minute behind live. Requires replication server license
etc.
Use SQL server DTS (or Integration Services or whatever its called this
year) + ODBC to transfer data as required from Progress to a SQL
reporting database. These can be entire tables on a schedule, or
triggered on demand from a stored procedure when somebody requests a
report. When using on-demand, you can pass user specified report
parameters into the DTS package, so it only pulls the few rows required
for the report. We did this in Vantage 6, and got slow-but-acceptable
report performance for live data.
Brian.
________________________________
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of sbraudrick@...
Sent: Wednesday, August 03, 2011 4:00 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: E9.05 conversion from Progress to SQL
It would / does, sort of. What I am doing now is moving data from
Progress to an old SQL 2000 instance I have using Data Transformation
Services. It works, but is only updated a few times a day because I
don't want to negatively impact the Progress performance.
I'm guessing I should look in to Replication server if I want more up to
date data in the reporting DB.
--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"cubcrafters_it" <jason.navarrete@...> wrote:
database to SQL for the purposes of reporting.
easier if we were a SQL environment. Has anyone done a conversion from
Progress to SQL? What would be involved?
reporting capabilities:
Convert your main database to SQL server. If you're already on Epicor
9.05, this requires a re-install of Epicor server software as well as
the database conversion.
Leave main database in Progress, and use replication server to copy to a
SQL server database for reporting etc. I believe the replicated data
runs about a minute behind live. Requires replication server license
etc.
Use SQL server DTS (or Integration Services or whatever its called this
year) + ODBC to transfer data as required from Progress to a SQL
reporting database. These can be entire tables on a schedule, or
triggered on demand from a stored procedure when somebody requests a
report. When using on-demand, you can pass user specified report
parameters into the DTS package, so it only pulls the few rows required
for the report. We did this in Vantage 6, and got slow-but-acceptable
report performance for live data.
Brian.
________________________________
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of sbraudrick@...
Sent: Wednesday, August 03, 2011 4:00 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: E9.05 conversion from Progress to SQL
It would / does, sort of. What I am doing now is moving data from
Progress to an old SQL 2000 instance I have using Data Transformation
Services. It works, but is only updated a few times a day because I
don't want to negatively impact the Progress performance.
I'm guessing I should look in to Replication server if I want more up to
date data in the reporting DB.
--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"cubcrafters_it" <jason.navarrete@...> wrote:
>Server Express if you DB is small enough) and replicate your Progress
> Sean,
>
> My understanding is that you can run a SQL reporting server (even SQL
database to SQL for the purposes of reporting.
>"sbraudrick@" <sbraudrick@> wrote:
> Would that work for you?
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
> >discovering that, for reporting and integration reasons, it might be
> > We're in a 9.05.603 / 10.2A Progress 64-bit environment and are
easier if we were a SQL environment. Has anyone done a conversion from
Progress to SQL? What would be involved?
> >[Non-text portions of this message have been removed]
> > Sean
> >
>