question re: read-only access to a database

jkj2001 · Post by **jkj2001** » Fri Aug 05, 2005 1:12 pm

We're experimenting with our Linux servers. We have a texis database on a SAN volume, mounted with read-write access from Linux box #1. Linux #2 sees the same volume, but mounted in a read-only fashion.

Searches from Linux #2 appear to be working, though of course I assume updates and inserts would not. However, is it possible that certain types of select queries will also not work? Perhaps certain ones require the use of lock or temporary semaphore files?

We're using a version of texis from October 2003, so we're fairly current, if it makes any difference. Just looking for reccomendations at this point, general thoughts. The main idea we're kicking around is to have one server handle loading new data and such, while the others would run queries against the tables throughout in a read-only fashion.

jkj2001 · Post by **jkj2001** » Mon Aug 08, 2005 11:30 am

Good stuff, John. Thanks.

Could I ask then, if it's possible to do what we're trying? That is, have a read-write copy of a texis database on one server, with read-only access from another, using a shared drive between the machines? Sounds like it'd be tough, but maybe there's another way.

jkj2001 · Post by **jkj2001** » Tue Aug 09, 2005 11:14 am

We'd be running updates at a moderate pace. Maybe touching 200 out of 20,000 records over the course of an 8 hour day.

Doesn't sound like the shared directory is going to work for us, so we'll keep digging...thanks for the information.

sourceone · Post by **sourceone** » Wed May 24, 2006 4:26 pm

I have a similar scenario in which I have a texis database on a SAN volume mounted to server #1 and server #2 has a shared drive pointing to the database. I'm getting an error 'No such file or directory in the function ddopen' when running a vortex script on server #2 that queries the database. Is the fact that the server is using a shared drive that's causing this error?

Post by **mark** » Wed May 24, 2006 4:50 pm

What's the filename for the "no such file" message?
If you have full paths in your SYSTABLES or SYSINDEX tables then the full paths of the files must match on both systems. In general you should have relative paths.