Re: Forms 3.0 and Oracle 8i (8.1.7) ( Invalid Rowid)

No, i've meant to patch the executables directly.

I'am not sure if this is illegal. The product is no longer supported by oracle. This could mean that the product is no longer a product. I am not an expert in laws, it may also depend in which country you are doing this. I've searched for a technical solution, and i am relativele sure that this will work pretty good and stable. A unsupported patch provided by oracle (i believe that this does exists even for their own old software) would do something similar.

The error "Moron" reported is from the SQL*Net interface or SQL*Forms itself,
i suppose. It checks the format of rowid when they are fetched or copied. Reverse ingeneering by oracle would simply cut out this test in the binary (e.g. replace the call to the function by a nop statement). Replacing a text in a binary that is never displayed on screen and never part of any copyright (the name "rowid") could also be considered not as reverse engineering.

Additionally i believe that if it is even a break of a law there is a relatively low risk that oracle or someone else will even notice it and do something against it. I suppose "Moron" wants to give support for old applications he has programmed a long time ago for his customers. Ok, it is something different if he wants to sell "SQL*Forms 3.0" for Oracle 8.x or 9.x databases. In that case Oracle will try to stop this, maybe illegal, procedure because they want to sell their new applications (but Forms is now free!).

Under the circumstances that Moron
* does not sell this "patched" SQL*Forms 3.0 version * Gives the version for free to well known and old

   customers (that payed for Forms 3.0 a long time ago) * Do not aquire new customers for this old application

   and sell them anything.
* Does not advertise for his old product and say that

   it is Oracle 8.x, 9.x compatible (with Forms 3.0) * Consults a lawer to double-check what's legal and

   illegal in his country (after checking the application    if it works with this "patch").

I do not see any problems in that case.

If Moron does this patching only on his development engines - and leave his customers unchanged with the old version - i see no problems at all.

Brgs.
Michael

"Frank" <fvanbortel_at_netscape.net> schrieb im Newsbeitrag news:3EAD8F5C.3010201_at_netscape.net...
> Michael Karg wrote:
> > Never tested, only an idea:
> >
> > Try reverse engineeing and replace all occurences of "rowid" in the
>
> Illegal to reverse engineer. Unless you mean the source (in the
> database). Even then, forms does this internally, so it won't help.
>
> > forms 3.0 binaries (and shared libs of the SQL*Net client forms 3.0
uses)
> > and also the forms generator (and
> > regenerate all forms) by an other colum name with the same number
> > of letters (e.g. rowix). Add this field to all corresponding tables in
your
> > database. Be sure to use a field type (e.g. varchar2) that is not longer
> > than an old DB 7.x rowid (i dont remember, it was shorter than the
> > new rowid introduced in oracle8 or has only a different format). Take a
look
> > on the format of the rowid in the old 7.x database documentation and use
> > exactly
> > the same length of varchar2 chars (e.g. rowix varchar2(13)).
> >
> > Write a pre insert trigger for each of these tables that fills in the
newly
> > created (v7 virtual rowid "rowix") in a similar format than the old 7.x
> > rowid values. Use a sequence to get unique numbers. You can use one
> > sequence for all corresponding tables. E.g (just an example - i do
> > not remember the old 7.x format), the old 7.x format was YYYY.NNNNNNNN
> > where YYYY is the Tablespace number, and NNNNNNNN the block number,
> > than you can generate the rowix by the use of the sequence number by the
> > following
> > code (core parts) of the pre-insert trigger
> > SELECT seq_rowix.nextval INTO seq FROM dual
> > :new.rowix:=TO_CHAR(MOD(seq/100000000,10000),'0999')||'.'||TO_CHAR(seq
MOD
> > 100000000),'09999999');
> >
> > Using this technique does not require to change anything in the
application,
> > you can generate the pre insert triggers for all tables easily
automatically
> > by an
> > sql script. Because you are using Forms 3.0 it is a high probability
that no
> > pre-insert triggers currently exists for these database - if so you have
to
> > modify them
> > rather than creating them.
> >
> > Hope this helps
> > Michael
> >
> > "Moron" <moron.jean-luc_at_rcc.ch> schrieb im Newsbeitrag
> > news:fa37b3cd.0304272244.5c760794_at_posting.google.com...
> >
> >>Frank <fvanbortel_at_netscape.net> wrote in message
> >
> > news:<3EAA9CB4.2010600_at_netscape.net>...
> >
> >>>Moron wrote:
> >>>
> >>>>Hi,
> >>>>
> >>>>as we are migrating our database onto Oracle 8i, we are expieriencing
> >>>>some
> >>>>Rowid problems.
> >>>>
> >>>>We already applied the "unsupported" patch which allows forms3 to
> >>>>connect on 8i databases.
> >>>
> >>>You already know it's a no-no situation; why pursue the impossible?
> >>>What's the reason for upgrading to 8i? Desupport of your current
> >>>version 6?
> >>>
> >>
> >>I am not sure it is impossible.
> >>I know that Oracle Application has had the same configuration
> >>(forms 3 against 8.x DB) .
> >>We even got a patch to solve another problem which was "fetch out of
> >>sequence" errors. This patch was'nt public, and not supported of
> >>course. The migration to Forms 6 is planed but is a huge workload and
> >>we would like to eliminate a 7.1 DB version. I was just hoping there
> >>was a solution for the related problems. The conversion on PK fields
> >>for the PLSQL code was envisaged but it doesn't make sens as long as a
> >>simple direct (without PLSQL Trigger) does not work.
> >>
> >>>>>After insert or update of a record, we get an error :FRM-40501 /
> >>>>
> > ORA-01410: invalid Rowid as soon as the record has been commited in the
DB
> > if we try to modify it again.
> >
> >>>>>PL SQL: any statement like " insert into table A() select () from
> >>>>
> > table B where Rowid = :My_block.rowid" raises exactly the same SQL
error.
> >
> >>>>
> >>>>Has somebody got the same troubles ?
> >>>
> >>>Yes - everyone trying to run V6 clients against V8i databases.
> >>>Forms V3 was desupported in the V7.1 days, somewhere last century.
> >>>Why not upgrade to a later version? Dev6i still supports the
> >>>c/s model...
> >>>
> >>>
> >>>>Is there any other patch or workaroud ?
> >>>>
> >>>
> >>>No patch. Workaround: you do all conversions from rowid to
> >>>primary key columns, or as suggested: redefine used rowid
> >>>columns to varchars.
> >>>Doubt if that works, though, as forms uses rowid internally.
> >>>That means you will get these errors on forms/blocks you never
> >>>defined a rowid field in.
> >>>Upgrade is the only w/a.
> >>
> >
> >
>
>
>
> --
> Regards, Frank van Bortel
>
Received on Tue Apr 29 2003 - 01:30:31 CDT