Prevent database cache

[favpennc]

Hello! Is there any option to force a fresh database connection with PCTConnection?
We've noticed that when we make non-crc changes to a database (adding new fields, sequences, etc), the database timestamp (_mstrblk._mstrblk-timestamp) isn't updated.
When we try compiling with Proant, PCTConnection connects to a cached version, and compiles fail with "field/sequence not found" even after they've been added.

[gquerret]

I'd need more details about the context, as PCTCompile always start a new ABL session. Is that related to the -cache option in your connection?

[favpennc]

Thanks for the reply!
We are intentionally not using the -cache option.

1 - We have source code that is compiling fine with our PCT compile script.
2 - We add a new field to the database (upload .df via Data Dictionary). We then update the source code to reference the new field.
3 - We try running our PCT compile again, and this time it fails with "newField not found." We are able to compile the file directly from the procedure editor.

Here's a sample block of how we're connecting/compiling:

  <target name="-pct-def">
    <taskdef resource="PCT.properties" />
    <typedef resource="types.properties" />
  </target>
  
  <target name="-db-connect" depends="-pct-def">	
      <PCTConnection id="dbid" dbName="name" logicalName="lname" dbDir="path" readOnly="true" singleUser="false" />
  </target>

  <target name="-compile" depends="-pct-def" >
    <PCTCompile destDir="path" dlcHome="path" >
      <fileset dir="path" includes="*.p" />
      <propath>
        <pathelement location="path" />
      </propath>
      <PCTConnection refid="dbid" />
    </PCTCompile>
  </target>

[gquerret]

There's no way PCTCompile could use a cached version, as no cache is being created by PCT. And you're using the -cache parameter. Use -v in your command line, you may get additional info. Maybe not connected to the right DB, or DB update transaction not committed...

[favpennc]

After talking with Progress, we set readOnly to false and that fixed it.
We use shared memory and they think readOnly was setting "-ro" on the db connection, which was causing it to not pick up the schema changes.

[gquerret]

Interesting case. I've been able to reproduce the issue:

• Start sports2000 broker (shared memory)
• Connect to the DB broker, add new table, then disconnect
• Connect to the DB with -RO ; a warning message is displayed at the beginning of the session, and the new table is not visible.
  I assume that this is what you see in your environment.

As soon as the DB broker is shut down, the read-only session can see the new table.

[favpennc]

That was it! Definitely an interesting situation.
Everything seems to be working great now. Thanks!