Re: Using Access to view and edit SQL Server table with Bigint primary key
- From: "Albert D. Kallal" <PleaseNOOOsPAMmkallal@xxxxxxx>
- Date: Tue, 18 Mar 2008 17:03:56 GMT
"Rich P" <rpng123@xxxxxxx> wrote in message
news:1205857974_395@xxxxxxxxxxxxxxxxxxxxx
Greetings,
Your problem has been an ongoing problem between Access and sql server
when using ODBC.
What ongoing problem you talking about here? Please explain.
the easiest workaround is to use
ADO to edit your data.
How are you going to convert a form to use ado? You mean now we going to
re-code all of our forms to now have code that builds recordsets in code,
and bind that to the form? That is NOT a easy workaround at all, and can
result in HUGE amounts of coding work for virtually ZERO discernable gain in
how that form is going to perform, or even function. And, using coded
recordsets will not work with sub-forms and the link master/child settings,
so we talking even MORE work here for anything with a sub-form.
Another workaround would be to use an
intermediate table, but you have to populate this table and once your
data is edited/updated/added you then still have to submit this data to
the main table which would require either some stored procedure - or
ADO.
Are you talking about a table on the local front end part, or back end?
Another workaround for that would be to keep
creating and assigning individual intermediate tables for each user
(until you run out of tables that you can add to the system
I can't imagine anyone suggesting temp tables on the sql server side, how
are we going to link our forms to these temp tables? I suppose one might
pull the data from sql server to some local tables in the access front end
that installed on each pc, but then you would NEVER run out of temp tables,
because each user would have a local table in which to edit the data. Again,
you going to have to clear up what you suggesting here..but, it don't make a
whole lot of sense. And, you code will not only have to check for updates,
but what about deleting records local, your code will now have to detect
this, and then delete the record on the server side (you can't just shuffle
records back and forth, you have to write additional code to deal with
deletions, since if you delete a record, and your code ONLY simply writes
back all of your records...you not take care of deletions.
All in all, if your suggesting to write code and build the reocrdsets in
ado, ms-access is the wrong tool to use here. Most of your suggestions will
result in all kinds of extra work for no gain in ms-access at all...
--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@xxxxxxx
.
- Follow-Ups:
- References:
- Prev by Date: Re: Sorting a report
- Next by Date: Re: Attaching files to a record using a subform
- Previous by thread: Re: Using Access to view and edit SQL Server table with Bigint primary key
- Next by thread: Re: Using Access to view and edit SQL Server table with Bigint primary key
- Index(es):
Relevant Pages
|