not expected behaviour of acFormAdd

[filo65]

Hi,

I have following situation:

- a back-end database containing tables
- a front end database containing forms

the fe form is via vba code linked to the table via a simple Query.

when I try to open the form ("frm1") with acFormadd property set to true doesn't look to work (It doesn't jump to the new record)

I would really appreciate any hint or solution to this funny problem.

Regards and thank in advance

Filippo

P.S.
I append be/fe_test databases; please take care to adjust the path

 

[RuralGuy]

It seems to be because you have chosen to set the RecordSource of the form in the Open event of the form rather than just binding the form to a linked table. Even though the DataEntry property is True, the form does not go to a new record even when opened directly.

 

[filo65]

Hi RuralGuy,

I think I got your point.

Instead of using:

set ... .Recordset = rs

I should use:

... .Recordsource ="SELECT * FROM Tab1 IN 'C:\...\be_test.mdb' "

I didn't try yet, but is it roughly what you mean?

Regards

Filippo

 

[RuralGuy]

Why not link the table and bind the form to the linked table?

 

[RuralGuy]

Here it is using a TableDef.

 

[filo65]

Hi RuralGuy,

Good point!


Some additional infos:

- my be is an Oracle server ( I can deal with it via ODBC or OO4O )
- multi-user fe ( up to 80 people )
- active write/reading operations
- massive Forms ( retrieving conditional queries, UNIONS etc. ); thís is a chief wish - I have probably to work hard on it

my idea would be to avoid any kind of link tables between fe and be to, not to overcharge the network.

Thank you for having taken the time and for the hints

Filippo

 

[Rabbie]

Hi RuralGuy,

Good point!


Some additional infos:

- my be is an Oracle server ( I can deal with it via ODBC or OO4O )
- multi-user fe ( up to 80 people )
- active write/reading operations
- massive Forms ( retrieving conditional queries, UNIONS etc. ); thís is a chief wish - I have probably to work hard on it

my idea would be to avoid any kind of link tables between fe and be to, not to overcharge the network.

Thank you for having taken the time and for the hints

Filippo

Just a couple of thoughts based on your remarks above.

If you have a multi-user FE Access database you run a very high risk of data corruption. Much better to give each user their own copy of FE which has the added advantage of reducing network traffic. There a several good tools available to make sure people have the latest FE. See this link for more info.

The point of splitting a DB is for the FE to have linked tables in the BE. How else would you access the data? AFAIK there is no network overhead if you are not fetching data.