A2002 bug: Can't set RecordsetType

  • Thread starter Vladimír Cvajniga
  • Start date
A

Allen Browne

There's no problem setting the RecordsetType in English (in form design
view.)

Internally the value is stored as a Byte, so if there is a problem with
setting it in your language, you may be able to set it programmatically.

With Form1 open in design view, press Ctrl+G to open the Immediate window,
and enter something like this:
Forms("Form1").RecordsetType = CByte(2)

Substitute the name of your form for Form1, and for 2 one of these:
0 Dynaset
1 Dynaset (Inconsistent Updates)
2 Snapshot
 
V

Vladimír Cvajniga

Thank you, Allen.

I've been using code to set RecordsetType property for a while. I just
wanted to know if it has to be done due to poor translation to Czech. :-(
It's also possible to set form's RecordSet property in VBA's properties
window... but not for query, of course.

Vlado

P.S. To show you what MS CZ translators do:
In MS Office 97's dictionary there's a translation of English 'n' (And), ie.
n in dictionary, to Czech a (a for Ano = Yes). As to the logic, the
translation is correct. But it's the following couple in the dictionary: n
=> a. Can you imagine automatic corrections in that case? Especially for
boolean A/N in Excel or Access?! (Ano/Ne = Yes/No). I don't know what are
these people paid for. :-(
I instruct people either do delete the "a n" couple from dictionary or not
to use automatic corrections at all...
 
A

Allen Browne

Sorry, Vlado: I can't comment on the translation into Czech part.

You can set the RecordsetType property for a query programmatically:
CurrentDb.QueryDefs("Query1").Properties("RecordsetType") = 0

Love your of A - N example. :)
 
V

Vladimír Cvajniga

For queries I've created a public function (about three months ago) so that
I can shorten the command in debug window to a simple ?fncQryN("qryName").
But instead of 0 I set 1 (Dynaset (Inconsistent Updates)) in fncQryN! ;-)

Vlado
 
T

Todos Menos [MSFT]

Vlad;

why in the hell would you use a MDB and DAO?

both of those have been obsolete for 10 years

seriously

use Access Data Projects.. it's a much better solution for projects
small, medium or large.
and of course-- ADO is _FASTER_ than DAO for _EVERYTHING_

if you're not putting performance first; then you don't care about
your customers
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top