anyone can solve this message ? :

"invalid device request writing device prn "

this message came out when this printing in progress …

Can someone solve this problem for me …

i'll be very thankfull

This suggests you don't have a parallel port. AREV predates Windows and so assumes that your machine will have an LPT1 which it opens as a file and prints to.

Until you can open a Command prompt and copy a text file to LPT1 (if the file were called TEST.TXT try COPY TEST.TXT LPT1) then AREV won't be able to.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

I had a similar problem on a Windows 98 machine with two parallel ports. Somebody had enabled printer and file sharing on this machine and it wouldn't recognize the redirections commands from Arev afterwards. If printer sharing has been enabled, try disabling it.

i have intall the port already but the problem still accured and i have disable the sharing printer function but stillican't print out

Can you make it work from DOS? If you cannot it is not an AREV problem.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

i can print document in the windows but i can't print invoice in AREV…….. could it be AREV system ?

Answer the Sprezz question:

What happens if you type

COPY TEST.TXT LPT1

in the DOS prompt.

Printing from windows is something else.

what you mean "Printing from windows is something else."

i still don't get it …. ? you mean print a test page in the dos… ?

There is "Command prompt" in the "Accessories" menu of a windows system. Invoke it.

Some thing like

C:\]

appears.

type "ECHO ] lpt1" and press Enter key

If the printer is configured properly for DOS programs the paper with text

echo is on

or with text

echo is off

should be printed.

If some error appears (or nothing is printed), solve this problem first.

Don't experiment with AREV before this.

There is no reason for further discussion without trying this.

WOO…… now it's works ..

i can't imagine that with this litle echo will

made up so many problem …….

by the way THANK YOU so much ……….

AND do you know how to export all the AREV system

to other database like : ms access or other else ????

hope you can reply it …….

Hmmm,

it depends on application,

The main problem is different philosophy of work with data.

Most fields in access like databases have fixed "length", so they either waste space or cannot handle longer data. The work with fields of nonconctant length is possible but not natural for them.

The other problem is the AREV application usually uses multivalued fields (divided into more levels).

The access like database solves this by creating more tables, but their relationship depends on rules multivalued fields are dependent. … No automatic method will work for it.

Last thing I should mention is that you can easily modify the table structure (adding fields in constant time) while other users are fully using the data required in AREV. This resuires table lock in access like databases (seems to me), so noone other can use the table at this time and the process takes time comparable to the table size.

Before I start maintaining our AREV application, I used these TCL commands to retrive required information:

PDISK

LIST … WITH

PDISK PRN

It was much more easier for me to learn AREV and maintain it.

Export of all the data and reprograming it in ACCESS like database seems to be rather difficult. And maintaining it when there are added functional reqirements is much more difficult, too.

BTW: I never left the method PDISK LIST PDISK to export data which can be processed more efficiently outside AREV (TeX processing of letters …), but the data are maintained in AREV.

I suppose this will not help you …

Robin,

Have you considered converting your AREV app to OI?

But if you must go the way of Access, we can help you later.

We have a utility that will import any Access file into an OI app. Long-run I think that you will find Access limited. That's how we came to build this utility since we have converted Access apps to OI.

Ray Chan

hippo]Most fields in access like databases have fixed "length", so they either waste space or cannot handle longer data. The work with fields of nonconctant length is possible but not natural for them.

hmm .. not 'really' true. use of varchar etc reduces this problem and with drive space being so cheap this is really a red herring ..

hippo] The other problem is the AREV application usually uses multivalued fields (divided into more levels).

The access like database solves this by creating more tables, but their relationship depends on rules multivalued fields are dependent. … No automatic method will work for it.

True .. dependent on the application itself. Most of my applications test toward 'normalized' and denormalizing as makes sense. This conversion is not really a big problem .. else we wouldn't have an odbc driver available. It normalizes on the fly .. (or it sure better)

There is no 'automatic method .. but it is easy enough to do. I convert MV systems to sqlServer and the other way .. I presented a paper at the first RTI (new) conference dealing with a MFS shell that moved data back and forth easily.

Hippo] Last thing I should mention is that you can easily modify the table structure (adding fields in constant time) while other users are fully using the data required in AREV. This resuires table lock in access like databases (seems to me), so noone other can use the table at this time and the process takes time comparable to the table size.

This is true .. but .. is this really a problem? Do you modify LIVE systems on the fly? Although this is possible normally LIVE systems are not modified with users accessing. Of course my habits are different from others etc .. so this is a toss up

'Post' relational is different from relational .. viva la difference (so why is it POST when it was defined and devloped before that hack CODD did his? boy I hope fabian pascal doesn't read this

dsig _at_ sigafoos.org.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

Robin,

As noted elsewhere the conversion of MV data can be problematic. There is no auto method of conversion/export but there are ways to convert. Depending on the design of your system the conversion may take a while to design.

Not sure of the version of Arev you have .. but if you know anyone with OI and the ODBC driver .. you might try reading the data with Excel and see where that gets you. It *should* normalise the rows on the fly .. note .. i haven't tried this but in theory

If you have any specific questions on moving data let us know ..

dsig _at_ sigafoos.org.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

Thanks for corrections, it's several years I've created an application in ACCESS … I've actually described just principles what I can remember;) … in this case I have had DBF's and their Memo implementation in mind, but the Access implementation can be more efficient.

BTW: Do you know how are the varchars stored in access? … I can remember the internal structure of the mdb's is rather complicated as they implement "internal file system", so the question can be rather hard to answer (fixed length fields first, other fields with forbidden delimiter or so).

You are right the HDD space is cheap, much more space is usually wasted by bad application design.

---

Yes I am modifying living system … it was used 5 years before I even know there is an AREV and there was actually noone in the company able to maintain it (except 3 external programmers trying to left the contract). The system seemed not to be able to fullfil requirements of growing company (batch jobs taking 32hours …). Now I am the only external programmer, the system is used for 12 years, seems not to have capacity problems, but there are parts I have not "configured well" yet and the new requirements are added … new laws generated by government …

Yes it will be possible to wait with upgrades until noone is in the system … but why:).

hippo] Thanks for corrections , it's several years I've created an application in ACCESS

more just pointing out the view from this side of the reality divide. Relationals (and i speak more of relationals … not specifically access)work well when designed well.

hippo]I've actually described just principles what I can remember;) … in this case I have had DBF's and their Memo implementation in mind, but the Access implementation can be more efficient.

dbf is dBase .. which though called relational .. it was as 'relational' as Arev is relational

hippo]BTW: Do you know how are the varchars stored in access? … I can remember the internal structure of the mdb's is rather complicated as they implement "internal file system", so the question can be rather hard to answer (fixed length fields first, other fields with forbidden delimiter or so).

.. no .. internal structures are only of interest to me when you HAVE to know them. This is 1 of 2 major draw backs I see in the OI (and mostly MV) world.

hippo]You are right the HDD space is cheap, much more space is usually wasted by bad application design.

yeah .. but sorry i used the 'cheap' card

hippo]The access like database solves this by creating more tables, but their relationship depends on rules multivalued fields are dependent. … No automatic method will work for it.

In ALL MV dbms except OI .. multivalued fields are (if associated) physically defined in a controlling/dependant scheme. This actually creates a 'table' within a table. For some reason the Arev (after 2.0) lost the Mx.n specification .. which makes it even 'less' than the other MVS. It becomes more dependant on the programming ability of the .. err .. programmer.

hippo] Last thing I should mention is that you can easily modify the table structure (adding fields in constant time) while other users are fully using the data required in AREV.

This is true .. but my wonder is .. how often do you really need to alter the table/database structure of a live system. Though technically correct this is a bad argument .. like my cheap HD space

dsig _at_ sigafoos.org.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

David Tod Sigafoos ~ SigSolutions

TO : RAY CHAN

thanks for the reminding … i will like to try the OI and ACCESS

but the problem is how to export all the old system to the new one …

hope to hear the solution from you and DSIG(SIGSOLUTION) ..

View this thread on the forum...