Recently I've been migrating our company from Corel Paradox for Dos to Paradox 11 for Windows and in the reports, i wanted to know how to make the reports universal rather than for one table.

For example, right now I have calculated fields defined as table-name.table-field however I'm not sure how to go about using the report for different tables.

I believe the DOS reports are universal because they don't specify table names in fields, however Paradox for Windows doesn't appear to allow this.

Any assistance is greatly appreacited

migrating from a 20-years dead platform, to a 10-years dead platform, isn't a great long-term position.. you should be noticing that the available support for PdoxWIN isn't much better than the available support for PdoxDOS.. you really really really need to get them to move in a different direction before you get hit by a bus..

the PdoxDOS table-field syntax was [table->field].. based on your last thread about calc fields, and this thread, you're still struggling with replacement syntax..

I got a new Vista laptop recently, and I haven't even bothered to put PdoxWIN on it yet because of all the Vista/BDE problems.. and because I'm not really in need of PdoxWIN anymore, myself..

there's nobody else with a strong Paradox background here, and you saw how little response you got over on the community forum.. you should have said "sorry Liz, that's not the solution I need".. that way, somebody might notice that you're still waiting..

sorry, but I can't offer much more than that..

Hi Steve,

Thanks for the validation. I agree that using Paradox has been a terrible idea, but I'm only paid to make the existing solution work -- my boss wants to stick with the existing system, which is why he recently bought WP office professional X4. Considering how Corel is charging me $150 per hour for support (to use the program features) I think now is the time to switch, especially since that's basically the most promising avenue of support (which already is terrible.

Thanks again for your attempted assistance and responses. I'm going to let my boss know right now that we need to switch. If we don't buy Access, I'll have to try Open Office Base.

corel is charging for top-dollar tech support in 2009, and all of the paradox developers and knowledge got laid off or fired in 2002.. sorry, but that's really funny.. sad, but funny..

Access?.. if you're gonna switch, you need to look at modern client-server packages.. nothing else has been supported or widely used for many years..

Thanks for the tidbit about the support, I so agree with that. I tried calling Corel using standard support and it seems like there's only one person there because of the five calls I placed over a month, I got the same (rude) person who was totally useless and unable to help.

When you say client/server I guess you mean PHP/SQL or something along those lines. We have a partially developed system like that, however we've been using Paradox (and now Access) because my boss is concerned about simplicity and having a well supported system.

Is it possible to use Access as a frontend for SQL/PHP. I remember seeing that somewhere and if so, that seems like a good compromise so our data would be long term, however our reports and such could just be switched over when we switch systems.

Our reports only tally data or display summaries/totals of data so we're not doing anything complex -- except maybe a few conditional calculated fields.

Right now it's my call as to what we do, so I suggested Access since I've worked with it for years and it seems to be the de-facto standard of databases (so it's simple to use). I agree that client/server is the best route, as Access is proprietary, but since we want something simple to pick up on, it appears using Access as a frontend and PHP for backend work will be the best route for now, until we have time to fully develop the PHP system.

Do you have any advice? Thanks again very much for your time with answering my questions.

the only thing I can really add to that, is that Access is the absolute worst "multi-user" platform out there.. but if you're just using it as a local front-end, there's no "multi-user" capability needed.. so it should be OK..