Marc,
For info I have e-mailed a version that uses SqlMetal's
Thank you.
I encountered two issues:
1. I need probably for WinForms GUI to trim trailing characters from CHAR
type columns and apply custom encoding conversion for all CHAR database
columns whose lenght is creater than 1.
In application init I'm planning to use
Vendor.StringConversion += (stringConversionEventArgs)=>
stringConversionEventArgs.Data.ToString().TrimEnd();
Code which implements this is:
class Vendor {
public class StringConversionEventArgs {
public object Data;
public Type Type;
public IDataRecord DataRecord;
public StringConversionEventArgs(object data, Type type, IDataRecord
dataRecord) {
Data = data;
Type = type;
DataRecord = dataRecord;
}
}
public static event Action<StringConversionEventArgs> StringConversion;
static string OnStringConversion(object data, Type type, IDataRecord
dataRecord) {
StringConversionEventArgs stringConversionEventArgs =
new StringConversionEventArgs(data, type, dataRecord);
if (StringConversion != null)
StringConversion(stringConversionEventArgs);
return stringConversionEventArgs.Data.ToString();
}
}
Unfortunately I do'nt know hot to add OnStringConversion() method call to
your code.
Also I don't know is this best design pattern to add global conversion
possibility.
2. It does not read properties without ColumnAttribute . MSDN describes
that it should:
<quote>
If a field or property is not mapped, a column with the same name as the
field or property is expected in the resultset.
Crude benchmarks show it slightly faster than raw LINQ-to-SQL, but it
is doing a lot less:
* no change tracking
I think it is possible to use Attach() method to add returned entities to
change tracking.
I do'nt know how to determine is the passed type part of DataContext or not.
I havent found DataContext method like
bool BelongsToThisDataContext( Type entity)
which can be used to test is Attach() valid. So I'm plannig to use crude
try/catch to add returned entites to DataContext in
some other method.
It made an interesting diversion, but I can't think of many cases when
I would use this instead of a data-context (ideally EF when RTM).
I'm planning to use it for queries against tables in database metadata.
I need to get list of available schemas and estimated number of records.
AFAIK , no one DLinq provides nor EF does not provide way nor generate
classes to access database metadata tables and views.
So ExecuteQuery<>() is the only way without falling back to DataSets.
Also this method allows to create entity type dynamically from script and
use this method to fill this dynamic entity with data.
Andrus.