Interesting Question

[Guest]

I have a pretty interesting situation where I need to compare database
elements against eachother.

Db1 = data feed from jailnet.us(can NOT write to)
Db2 = runs queries against Db1(can write to), creates reports

Db2 can not write to Db1! And query's can not be ran through Db1.

Db2 calls against Db1 to query for information I1, I2, etc...

Db2 needs to compare how Db1 reacted last time Db2 was ran. But need to
write to Db2 and "remember" what happened. I only want to see information
that has not been printed. Db2 has (at this point) only linked tables
except for one table that "feeds" customer info to reports.

(For example: I1 that was printed by Db2, won't reprint when I2 is seen. )

Any ideas here?

Thanks,

Blaze

 

[Guest]

Blaze,

It looks like you have a series of programmatical events that you need to
capture before running your query. You might want to describe in more detail
exactly what you've done and are trying to get to.

Mark

 

[Guest]

Okay...

Db1 - is a SQL site that runs Sharepoint Services where all the Data entry
is done.

Db2 - is an Access DB that has linked tables to the Sharepoint site.

Db2 - is where the queries and the reports are written from Db1.

Db1 - is not writeable and only querieable.

When the report from Db2 reports and prints a group of reports, (lets say
from Sept 1 - Sept 30th, I need to "mark" them as printed so that I can run a
report quarterly that shows what hasn't been printed.

Is this enough?

Blaze

 

[Guest]

Blaze,

Since, you're using DB2 as a front end, I would create a table in DB2 that
would contain a list of the reports that have been printed. Then I would
create a form to hold the reports which would hold a list box hold the
reports that the user can run.

You would have to write a routine to populate the list box when the form
opens by looking at the reports that are available and not including the
reports that have been printed.

You would also have to write a routine that would update the table in your
front end when the report is printed, and to refresh the list box once the
reports are done.

That being said, I see a number of problems in this situation.

1. If you are using a distributed front end, then the same report could be
run from multiple PC's because the table the hold the printed report list is
local to each front end.

2. Murphy's Law will dicate the reports won't print or they'll get lost on
the printer, and your user can't go back and re-print them.

You might want to re-think this a little bit.

Mark


Mark

 

[Guest]

Good point. I'm not good enough to do this anyhow. I will just make sure
they run monthly reports and save them, then compare to a quarterly report to
verify the numbers and reports are equal.

Thanks for the help!

Blaze