Data table retrieval using column name or integer
So, just looking for a general rule of thumb here, and could not seem to find a legitimate method to go forward with. I see both often.
Essentially you have something like this:
DataTable dt = new DataTable();
dt blah blah blah .Fill
Now accessing:
dt.Rows[i]["ColumnName"].ToString();
dt.Rows[i][ColumnInteger].ToString();
So the question is, I see the merits of both. Changing a column name in the table one day, would have no effect if we had been using the integer. On the same side, using the column name definitely seems easier from a readability side. Or maybe there is a reason to pick one over the other from a performance perspective.
So really, what do you all see in consistent practice?
c# sql datatable
add a comment |
So, just looking for a general rule of thumb here, and could not seem to find a legitimate method to go forward with. I see both often.
Essentially you have something like this:
DataTable dt = new DataTable();
dt blah blah blah .Fill
Now accessing:
dt.Rows[i]["ColumnName"].ToString();
dt.Rows[i][ColumnInteger].ToString();
So the question is, I see the merits of both. Changing a column name in the table one day, would have no effect if we had been using the integer. On the same side, using the column name definitely seems easier from a readability side. Or maybe there is a reason to pick one over the other from a performance perspective.
So really, what do you all see in consistent practice?
c# sql datatable
add a comment |
So, just looking for a general rule of thumb here, and could not seem to find a legitimate method to go forward with. I see both often.
Essentially you have something like this:
DataTable dt = new DataTable();
dt blah blah blah .Fill
Now accessing:
dt.Rows[i]["ColumnName"].ToString();
dt.Rows[i][ColumnInteger].ToString();
So the question is, I see the merits of both. Changing a column name in the table one day, would have no effect if we had been using the integer. On the same side, using the column name definitely seems easier from a readability side. Or maybe there is a reason to pick one over the other from a performance perspective.
So really, what do you all see in consistent practice?
c# sql datatable
So, just looking for a general rule of thumb here, and could not seem to find a legitimate method to go forward with. I see both often.
Essentially you have something like this:
DataTable dt = new DataTable();
dt blah blah blah .Fill
Now accessing:
dt.Rows[i]["ColumnName"].ToString();
dt.Rows[i][ColumnInteger].ToString();
So the question is, I see the merits of both. Changing a column name in the table one day, would have no effect if we had been using the integer. On the same side, using the column name definitely seems easier from a readability side. Or maybe there is a reason to pick one over the other from a performance perspective.
So really, what do you all see in consistent practice?
c# sql datatable
c# sql datatable
edited Nov 13 '18 at 18:47
Erik Philips
41k691124
41k691124
asked Nov 13 '18 at 18:44
CMRCMR
859
859
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
So really, what do you all see in consistent practice?
They both exist for a reason, they're both useful when the other isn't. You're always going to be tightly coupled to a table in SQL land. It's just your choice if you want to couple it via column index or string.
In practice, I've never designed a system to use Data Tables. I have a strongly typed Object Oriented Language so I choose to use objects over generic data containers.
There are ORM frameworks like Entity Framework (microsoft), Dapper, NHibernate and more that allow your Database Row (XML nodes, Json Object etc) to represent a .net Object (defined, anonymous and sometimes Tuples). The goal is to take a data from a storage system system and convert your request into a class. After retrieving data;
A Data Table Might look like:
[1]Id [2]FirstName [3]LastName
(int) (string) (string)
--------------------------------------------
1 Erik Philips
So computing a Full Name becomes code that looks like:
var fullName = $"{dt.Rows[i][2].ToString()} {dt.Rows[i][3].ToString()}";
or
var fullName = $"{dt.Rows[i]["FirstName"].ToString()} {dt.Rows[i]["LastName"].ToString()}";
Which does it's job but the logic in an Object Oriented Language should be encapsulated. Using an ORM your data is requested via a class that represents data access and is configured to get the data and map it (which I won't go into detail about the specifics). First you start by creating a POCO:
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
and then you ask for them via the Data Access Class;
Entity Framework (DbContext)
var person = DbContext.Persons.FirstOrDefault(p => p.id == 1);
// OR
var person = DbContext.Set<Person>().FirstOrDefault(p => p.id == 1);
Dapper: (*I've not used dapper so this might be technically wrong but you get the idea)
var person = connection.Query<Person>("Select * FROM CUSTOMERS WHERE Id = 1").FirstOrDefault()
NHibernate:
var person = session.Get<Person>(Id);
In all these instances you get back a Person class/object. Now we can encapsulate business logic (we need to have a consistent way to represent "Full Name" to our data consumers).
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public DateTime BornOn { get; set; }
public boolean IsMarried { get; set; }
public string FullName
{
get
{
return $"{FirstName} {LastName}";
}
}
}
but is that the main goal of it all?
In my personal opinion, the goal of it all is to aid the developer writing good code, which includes (items relevant to the question I'll comment on);
using the S.O.L.I.D. Principles:
Single responsibility principle
// What else could this class possibly be used for?
public class Person ....
Writing readable code with as little documentation as possible.
var tom = dbContext.Persons.FirstOrDefault(p => p.FirstName == "Tom");
if (tom.IsMarried) ...
if (tom.BornOn > DateTime.Now) ...
To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.
– MikeH
Nov 13 '18 at 18:54
1
Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.
– CMR
Nov 13 '18 at 20:04
Yeah mark whatever answer works for you :)
– Erik Philips
Nov 13 '18 at 20:51
@ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?
– CMR
Nov 14 '18 at 15:06
Lightly updated my answer based on your question.
– Erik Philips
Nov 14 '18 at 18:15
|
show 5 more comments
This won't answer the "what is the right way" question, but if you want to maintain readability while still using indexes you could create an enum
:
enum ColumnNames
{
FirstName = 1,
LastName =2,
}
dt.Rows[i][(int)ColumnNames.FirstName].ToString();
Love it, using it, this is the right way lol. Best of both worlds here.
– CMR
Nov 13 '18 at 20:01
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53287608%2fdata-table-retrieval-using-column-name-or-integer%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
So really, what do you all see in consistent practice?
They both exist for a reason, they're both useful when the other isn't. You're always going to be tightly coupled to a table in SQL land. It's just your choice if you want to couple it via column index or string.
In practice, I've never designed a system to use Data Tables. I have a strongly typed Object Oriented Language so I choose to use objects over generic data containers.
There are ORM frameworks like Entity Framework (microsoft), Dapper, NHibernate and more that allow your Database Row (XML nodes, Json Object etc) to represent a .net Object (defined, anonymous and sometimes Tuples). The goal is to take a data from a storage system system and convert your request into a class. After retrieving data;
A Data Table Might look like:
[1]Id [2]FirstName [3]LastName
(int) (string) (string)
--------------------------------------------
1 Erik Philips
So computing a Full Name becomes code that looks like:
var fullName = $"{dt.Rows[i][2].ToString()} {dt.Rows[i][3].ToString()}";
or
var fullName = $"{dt.Rows[i]["FirstName"].ToString()} {dt.Rows[i]["LastName"].ToString()}";
Which does it's job but the logic in an Object Oriented Language should be encapsulated. Using an ORM your data is requested via a class that represents data access and is configured to get the data and map it (which I won't go into detail about the specifics). First you start by creating a POCO:
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
and then you ask for them via the Data Access Class;
Entity Framework (DbContext)
var person = DbContext.Persons.FirstOrDefault(p => p.id == 1);
// OR
var person = DbContext.Set<Person>().FirstOrDefault(p => p.id == 1);
Dapper: (*I've not used dapper so this might be technically wrong but you get the idea)
var person = connection.Query<Person>("Select * FROM CUSTOMERS WHERE Id = 1").FirstOrDefault()
NHibernate:
var person = session.Get<Person>(Id);
In all these instances you get back a Person class/object. Now we can encapsulate business logic (we need to have a consistent way to represent "Full Name" to our data consumers).
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public DateTime BornOn { get; set; }
public boolean IsMarried { get; set; }
public string FullName
{
get
{
return $"{FirstName} {LastName}";
}
}
}
but is that the main goal of it all?
In my personal opinion, the goal of it all is to aid the developer writing good code, which includes (items relevant to the question I'll comment on);
using the S.O.L.I.D. Principles:
Single responsibility principle
// What else could this class possibly be used for?
public class Person ....
Writing readable code with as little documentation as possible.
var tom = dbContext.Persons.FirstOrDefault(p => p.FirstName == "Tom");
if (tom.IsMarried) ...
if (tom.BornOn > DateTime.Now) ...
To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.
– MikeH
Nov 13 '18 at 18:54
1
Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.
– CMR
Nov 13 '18 at 20:04
Yeah mark whatever answer works for you :)
– Erik Philips
Nov 13 '18 at 20:51
@ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?
– CMR
Nov 14 '18 at 15:06
Lightly updated my answer based on your question.
– Erik Philips
Nov 14 '18 at 18:15
|
show 5 more comments
So really, what do you all see in consistent practice?
They both exist for a reason, they're both useful when the other isn't. You're always going to be tightly coupled to a table in SQL land. It's just your choice if you want to couple it via column index or string.
In practice, I've never designed a system to use Data Tables. I have a strongly typed Object Oriented Language so I choose to use objects over generic data containers.
There are ORM frameworks like Entity Framework (microsoft), Dapper, NHibernate and more that allow your Database Row (XML nodes, Json Object etc) to represent a .net Object (defined, anonymous and sometimes Tuples). The goal is to take a data from a storage system system and convert your request into a class. After retrieving data;
A Data Table Might look like:
[1]Id [2]FirstName [3]LastName
(int) (string) (string)
--------------------------------------------
1 Erik Philips
So computing a Full Name becomes code that looks like:
var fullName = $"{dt.Rows[i][2].ToString()} {dt.Rows[i][3].ToString()}";
or
var fullName = $"{dt.Rows[i]["FirstName"].ToString()} {dt.Rows[i]["LastName"].ToString()}";
Which does it's job but the logic in an Object Oriented Language should be encapsulated. Using an ORM your data is requested via a class that represents data access and is configured to get the data and map it (which I won't go into detail about the specifics). First you start by creating a POCO:
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
and then you ask for them via the Data Access Class;
Entity Framework (DbContext)
var person = DbContext.Persons.FirstOrDefault(p => p.id == 1);
// OR
var person = DbContext.Set<Person>().FirstOrDefault(p => p.id == 1);
Dapper: (*I've not used dapper so this might be technically wrong but you get the idea)
var person = connection.Query<Person>("Select * FROM CUSTOMERS WHERE Id = 1").FirstOrDefault()
NHibernate:
var person = session.Get<Person>(Id);
In all these instances you get back a Person class/object. Now we can encapsulate business logic (we need to have a consistent way to represent "Full Name" to our data consumers).
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public DateTime BornOn { get; set; }
public boolean IsMarried { get; set; }
public string FullName
{
get
{
return $"{FirstName} {LastName}";
}
}
}
but is that the main goal of it all?
In my personal opinion, the goal of it all is to aid the developer writing good code, which includes (items relevant to the question I'll comment on);
using the S.O.L.I.D. Principles:
Single responsibility principle
// What else could this class possibly be used for?
public class Person ....
Writing readable code with as little documentation as possible.
var tom = dbContext.Persons.FirstOrDefault(p => p.FirstName == "Tom");
if (tom.IsMarried) ...
if (tom.BornOn > DateTime.Now) ...
To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.
– MikeH
Nov 13 '18 at 18:54
1
Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.
– CMR
Nov 13 '18 at 20:04
Yeah mark whatever answer works for you :)
– Erik Philips
Nov 13 '18 at 20:51
@ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?
– CMR
Nov 14 '18 at 15:06
Lightly updated my answer based on your question.
– Erik Philips
Nov 14 '18 at 18:15
|
show 5 more comments
So really, what do you all see in consistent practice?
They both exist for a reason, they're both useful when the other isn't. You're always going to be tightly coupled to a table in SQL land. It's just your choice if you want to couple it via column index or string.
In practice, I've never designed a system to use Data Tables. I have a strongly typed Object Oriented Language so I choose to use objects over generic data containers.
There are ORM frameworks like Entity Framework (microsoft), Dapper, NHibernate and more that allow your Database Row (XML nodes, Json Object etc) to represent a .net Object (defined, anonymous and sometimes Tuples). The goal is to take a data from a storage system system and convert your request into a class. After retrieving data;
A Data Table Might look like:
[1]Id [2]FirstName [3]LastName
(int) (string) (string)
--------------------------------------------
1 Erik Philips
So computing a Full Name becomes code that looks like:
var fullName = $"{dt.Rows[i][2].ToString()} {dt.Rows[i][3].ToString()}";
or
var fullName = $"{dt.Rows[i]["FirstName"].ToString()} {dt.Rows[i]["LastName"].ToString()}";
Which does it's job but the logic in an Object Oriented Language should be encapsulated. Using an ORM your data is requested via a class that represents data access and is configured to get the data and map it (which I won't go into detail about the specifics). First you start by creating a POCO:
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
and then you ask for them via the Data Access Class;
Entity Framework (DbContext)
var person = DbContext.Persons.FirstOrDefault(p => p.id == 1);
// OR
var person = DbContext.Set<Person>().FirstOrDefault(p => p.id == 1);
Dapper: (*I've not used dapper so this might be technically wrong but you get the idea)
var person = connection.Query<Person>("Select * FROM CUSTOMERS WHERE Id = 1").FirstOrDefault()
NHibernate:
var person = session.Get<Person>(Id);
In all these instances you get back a Person class/object. Now we can encapsulate business logic (we need to have a consistent way to represent "Full Name" to our data consumers).
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public DateTime BornOn { get; set; }
public boolean IsMarried { get; set; }
public string FullName
{
get
{
return $"{FirstName} {LastName}";
}
}
}
but is that the main goal of it all?
In my personal opinion, the goal of it all is to aid the developer writing good code, which includes (items relevant to the question I'll comment on);
using the S.O.L.I.D. Principles:
Single responsibility principle
// What else could this class possibly be used for?
public class Person ....
Writing readable code with as little documentation as possible.
var tom = dbContext.Persons.FirstOrDefault(p => p.FirstName == "Tom");
if (tom.IsMarried) ...
if (tom.BornOn > DateTime.Now) ...
So really, what do you all see in consistent practice?
They both exist for a reason, they're both useful when the other isn't. You're always going to be tightly coupled to a table in SQL land. It's just your choice if you want to couple it via column index or string.
In practice, I've never designed a system to use Data Tables. I have a strongly typed Object Oriented Language so I choose to use objects over generic data containers.
There are ORM frameworks like Entity Framework (microsoft), Dapper, NHibernate and more that allow your Database Row (XML nodes, Json Object etc) to represent a .net Object (defined, anonymous and sometimes Tuples). The goal is to take a data from a storage system system and convert your request into a class. After retrieving data;
A Data Table Might look like:
[1]Id [2]FirstName [3]LastName
(int) (string) (string)
--------------------------------------------
1 Erik Philips
So computing a Full Name becomes code that looks like:
var fullName = $"{dt.Rows[i][2].ToString()} {dt.Rows[i][3].ToString()}";
or
var fullName = $"{dt.Rows[i]["FirstName"].ToString()} {dt.Rows[i]["LastName"].ToString()}";
Which does it's job but the logic in an Object Oriented Language should be encapsulated. Using an ORM your data is requested via a class that represents data access and is configured to get the data and map it (which I won't go into detail about the specifics). First you start by creating a POCO:
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
and then you ask for them via the Data Access Class;
Entity Framework (DbContext)
var person = DbContext.Persons.FirstOrDefault(p => p.id == 1);
// OR
var person = DbContext.Set<Person>().FirstOrDefault(p => p.id == 1);
Dapper: (*I've not used dapper so this might be technically wrong but you get the idea)
var person = connection.Query<Person>("Select * FROM CUSTOMERS WHERE Id = 1").FirstOrDefault()
NHibernate:
var person = session.Get<Person>(Id);
In all these instances you get back a Person class/object. Now we can encapsulate business logic (we need to have a consistent way to represent "Full Name" to our data consumers).
public class Person
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public DateTime BornOn { get; set; }
public boolean IsMarried { get; set; }
public string FullName
{
get
{
return $"{FirstName} {LastName}";
}
}
}
but is that the main goal of it all?
In my personal opinion, the goal of it all is to aid the developer writing good code, which includes (items relevant to the question I'll comment on);
using the S.O.L.I.D. Principles:
Single responsibility principle
// What else could this class possibly be used for?
public class Person ....
Writing readable code with as little documentation as possible.
var tom = dbContext.Persons.FirstOrDefault(p => p.FirstName == "Tom");
if (tom.IsMarried) ...
if (tom.BornOn > DateTime.Now) ...
edited Nov 14 '18 at 18:15
answered Nov 13 '18 at 18:53
Erik PhilipsErik Philips
41k691124
41k691124
To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.
– MikeH
Nov 13 '18 at 18:54
1
Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.
– CMR
Nov 13 '18 at 20:04
Yeah mark whatever answer works for you :)
– Erik Philips
Nov 13 '18 at 20:51
@ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?
– CMR
Nov 14 '18 at 15:06
Lightly updated my answer based on your question.
– Erik Philips
Nov 14 '18 at 18:15
|
show 5 more comments
To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.
– MikeH
Nov 13 '18 at 18:54
1
Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.
– CMR
Nov 13 '18 at 20:04
Yeah mark whatever answer works for you :)
– Erik Philips
Nov 13 '18 at 20:51
@ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?
– CMR
Nov 14 '18 at 15:06
Lightly updated my answer based on your question.
– Erik Philips
Nov 14 '18 at 18:15
To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.
– MikeH
Nov 13 '18 at 18:54
To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.
– MikeH
Nov 13 '18 at 18:54
1
1
Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.
– CMR
Nov 13 '18 at 20:04
Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.
– CMR
Nov 13 '18 at 20:04
Yeah mark whatever answer works for you :)
– Erik Philips
Nov 13 '18 at 20:51
Yeah mark whatever answer works for you :)
– Erik Philips
Nov 13 '18 at 20:51
@ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?
– CMR
Nov 14 '18 at 15:06
@ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?
– CMR
Nov 14 '18 at 15:06
Lightly updated my answer based on your question.
– Erik Philips
Nov 14 '18 at 18:15
Lightly updated my answer based on your question.
– Erik Philips
Nov 14 '18 at 18:15
|
show 5 more comments
This won't answer the "what is the right way" question, but if you want to maintain readability while still using indexes you could create an enum
:
enum ColumnNames
{
FirstName = 1,
LastName =2,
}
dt.Rows[i][(int)ColumnNames.FirstName].ToString();
Love it, using it, this is the right way lol. Best of both worlds here.
– CMR
Nov 13 '18 at 20:01
add a comment |
This won't answer the "what is the right way" question, but if you want to maintain readability while still using indexes you could create an enum
:
enum ColumnNames
{
FirstName = 1,
LastName =2,
}
dt.Rows[i][(int)ColumnNames.FirstName].ToString();
Love it, using it, this is the right way lol. Best of both worlds here.
– CMR
Nov 13 '18 at 20:01
add a comment |
This won't answer the "what is the right way" question, but if you want to maintain readability while still using indexes you could create an enum
:
enum ColumnNames
{
FirstName = 1,
LastName =2,
}
dt.Rows[i][(int)ColumnNames.FirstName].ToString();
This won't answer the "what is the right way" question, but if you want to maintain readability while still using indexes you could create an enum
:
enum ColumnNames
{
FirstName = 1,
LastName =2,
}
dt.Rows[i][(int)ColumnNames.FirstName].ToString();
answered Nov 13 '18 at 18:51
MikeHMikeH
3,2691028
3,2691028
Love it, using it, this is the right way lol. Best of both worlds here.
– CMR
Nov 13 '18 at 20:01
add a comment |
Love it, using it, this is the right way lol. Best of both worlds here.
– CMR
Nov 13 '18 at 20:01
Love it, using it, this is the right way lol. Best of both worlds here.
– CMR
Nov 13 '18 at 20:01
Love it, using it, this is the right way lol. Best of both worlds here.
– CMR
Nov 13 '18 at 20:01
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53287608%2fdata-table-retrieval-using-column-name-or-integer%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown