dancefloorlandmine (
dancefloorlandmine) wrote2004-09-21 12:09 pm
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
[SQL/Access] Evil Database of Doom
There appears to be a slight glitch, in that an unnecessarily complicated process is not working correctly.
Background information
The database is running on SQL Server, with a Microsloth Abscess 2000 front end on each relevant desktop, using linked tables.
Problem
The developer created a drop-down to enable the selection of previous contacts. This then triggered a macro (mutter mutter) which ran a Refresh operation, and a pair of queries (no, I don’t know why a pair either), which populated the main table with data from the saved information on the previous contact. However, this does not then display on the form on screen. Just to add to the fun, most users will view the form with the "Data Entry" property set to True.
When, on the test database, the tables were imported instead of linked, and a “repaint” operation solved the problem. However, when using the linked tables on the real thing, nowt - the repaint doesn't seem to work.
Anyone got any ideas?
Background information
The database is running on SQL Server, with a Microsloth Abscess 2000 front end on each relevant desktop, using linked tables.
Problem
The developer created a drop-down to enable the selection of previous contacts. This then triggered a macro (mutter mutter) which ran a Refresh operation, and a pair of queries (no, I don’t know why a pair either), which populated the main table with data from the saved information on the previous contact. However, this does not then display on the form on screen. Just to add to the fun, most users will view the form with the "Data Entry" property set to True.
When, on the test database, the tables were imported instead of linked, and a “repaint” operation solved the problem. However, when using the linked tables on the real thing, nowt - the repaint doesn't seem to work.
Anyone got any ideas?
no subject
Personally, I much prefer VBA to macros. Unfortunately, it would appear that the "writing to" stuff is done using an update query, so it is copying data across, rather than performing it using the form's controls.
The [cough] so-called developer (who knew less than I do about Access when she started on this project) has now returned to the Antipodes, from where she's attempting to give remote support via email (ultimate arms-reach support).
no subject
This is actualy the correct way to talk to the SQL server for edits. The alternative, binding the controls and/or form to the table via the linking would do horrible things to the server.
If they only could have done the same for reading :o/
no subject
no subject
no subject