| .NET DotNet Forum Index » ADO .NET Forum » Multivalued Fields in Access 2007 with C# ADO?... |
|
Page 1 of 1 |
|
| Author |
Message |
| George Lee... |
 Posted: Mon Oct 05, 2009 10:36 am |
|
|
|
Guest
|
How do you read/write multivalued fields in Access 2007 with ADO.NET C#?
I've asked other Usenet groups and there has not been much help. |
|
|
| Back to top |
|
|
|
| Mark Rae [MVP]... |
| Posted: Mon Oct 05, 2009 10:49 am |
|
|
|
Guest
|
"George Lee" <georgelee12000 at (no spam) yahoo.com> wrote in message
news:1aqdnfuMlorlvVfXnZ2dnUVZ_v6dnZ2d at (no spam) posted.isomediainc...
Quote: How do you read/write multivalued fields in Access 2007 with ADO.NET C#?
http://tinyurl.com/yck6ma9
--
Mark Rae
ASP.NET MVP
http://www.markrae.net |
|
|
| Back to top |
|
|
|
| Mark Rae [MVP]... |
| Posted: Mon Oct 05, 2009 2:06 pm |
|
|
|
Guest
|
"George Lee" <GeorgeLee at (no spam) discussions.microsoft.com> wrote in message
news:432DEC4A-B503-4CCB-94E8-7C6CDCD69AA7 at (no spam) microsoft.com...
[please don't top-post]
Quote: How do you read/write multivalued fields in Access 2007 with ADO.NET C#?
http://tinyurl.com/yck6ma9
For the following code, the DAO approach would be to create another
recordset
based on the parent and loop through it. Is there an ADO equivalent?
DataSet ds = new DataSet();
myAdapter.Fill(ds);
Not sure what you mean - that's ADO.NET...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net |
|
|
| Back to top |
|
|
|
| Jesse Houwing... |
| Posted: Mon Oct 05, 2009 3:22 pm |
|
|
|
Guest
|
* Mark Rae [MVP] wrote, On 5-10-2009 22:06:
Quote: "George Lee" <GeorgeLee at (no spam) discussions.microsoft.com> wrote in message
news:432DEC4A-B503-4CCB-94E8-7C6CDCD69AA7 at (no spam) microsoft.com...
[please don't top-post]
How do you read/write multivalued fields in Access 2007 with ADO.NET
C#?
http://tinyurl.com/yck6ma9
For the following code, the DAO approach would be to create another
recordset
based on the parent and loop through it. Is there an ADO equivalent?
DataSet ds = new DataSet();
myAdapter.Fill(ds);
Not sure what you mean - that's ADO.NET...
The query syntax can be found here:
http://office.microsoft.com/en-us/access/HA101492971033.aspx
When doing a select, you'll get all the values that were in the
multivalued fields separated by ;.
You will have to split them manually if you want to use them for a data
binding scenario. There is no multi-valued field datatype that you can
select for the column in a dataset.
I'd recommend using a separate table instead of multi-valued fields.
They're a kind of poor-mans-solution for database design. You won't be
able to upgrade the database to any other "real" database solution.
Neither Oracle nor SQL Server supports these kinds of fields in their
table design nor in their query syntax.
So steer away while you still can  .
--
Jesse Houwing
jesse.houwing at sogeti.nl |
|
|
| Back to top |
|
|
|
| Mark Rae [MVP]... |
| Posted: Mon Oct 05, 2009 3:47 pm |
|
|
|
Guest
|
"Jesse Houwing" <jesse.houwing at (no spam) newsgroup.nospam> wrote in message
news:%23jlG8HgRKHA.220 at (no spam) TK2MSFTNGP02.phx.gbl...
Quote: So steer away while you still can .
I couldn't agree more, but you're replying to the wrong post...
--
Mark Rae
ASP.NET MVP
http://www.markrae.net |
|
|
| Back to top |
|
|
|
| Mary Chipman [MSFT]... |
| Posted: Thu Oct 08, 2009 8:01 am |
|
|
|
Guest
|
On Wed, 7 Oct 2009 14:23:01 -0700, George Lee
<GeorgeLee at (no spam) discussions.microsoft.com> wrote:
Quote: The Sharepoint context makes sense but I still have to work with these
files, and often don’t have the ability to redesign them since they are being
used by others for other purposes. Do do have any good code examples how to
access those fields programmatically?
I don't have any code handy, but it would involve basic string parsing
functions. I'd initiate a search for free code examples--I'm sure
you're not the first person who's had to parse multi-valued fields for
an app How much data is involved? If the answer is "a lot" then
you'll not want to process large result sets, or you could be facing a
considerable perf hit. If that is the case, it might be a better
option to maintain two sets of the same data, one relational for your
..NET app, and the other for Access-Sharepoint users. You'd need to do
this in the back end database to ensure accuracy and consistency,
which isn't that easy to do in Access (no triggers). But at least
you'd be working with relational data, and your back end would convert
more easily to SQL Server when the time comes. Using Access/Jet/ACE as
the data store just doesn't work for most .NET scenarios.
--Mary |
|
|
| Back to top |
|
|
|
|
