|
|
|
|
Hi,
I downloaded cedb.net code
I am facing problem in reading FileTime property.
for ex: in the database the value of the FileTime properties is "19/05/2006 12:12:00"
while reading the FileTime Property. it class the GetValue() inside the CeDBProperty class.
****Code*******
return new DateTime(BitConverter.ToInt64(m_prop, 8));
****Code*******
but the problem is after returing the value = "19/05/406"
i getting only the value of year is wrong and all other values(date and month) are correct. what is the problem in the conversion ?...
on the same way while setting the Value also.
Kindly reply me with your valueable comments..
Thanks & regards,
Rajesh. S
|
|
|
|
|
|
|
|
|
|
|
|
After developing Data Port Wizard and Data Port Command, I'm starting to develop a C# Assembly for desktop applications that will encapsulate all the Data Port C++ code. To test the C# code, I am developing a C# application to edit SQL CE databases on the desktop: SQL CE Console. As of today, I'm posting the application on the downloads section of my site[^]. All comments and suggestions are welcome.
|
|
|
|
|
I just found another nasty bug on the original implementation of atldbcli.h : the AddOffset method of CDynamicAccessor . The original version of the method fails for odd values of the nAdd parameter:
static ULONG AddOffset(ULONG nCurrent, ULONG nAdd)
{
struct foobar
{
char foo;
long bar;
};
ULONG nAlign = offsetof(foobar, bar);
return nCurrent + nAdd + (nAdd % nAlign);
}
The purpose of this method is to add sizes or offsets using the default CPU padding (4 bytes for most of them). If you follow the method's logic, you will see that it will only work for even values of nAdd . If you feed it with an odd value, you will end up with a result that is not divisible by 4, meaning that you will get a data type misalignement error when accessing memory through an offset calculated this way.
Here is a possible solution:
static ULONG AddOffset(ULONG nCurrent, ULONG nAdd)
{
struct foobar
{
char foo;
long bar;
};
ULONG nAlign = offsetof(foobar, bar),
nRet,
nMod;
nRet = nCurrent + nAdd;
nMod = nRet % nAlign;
if(nMod)
nRet += nAlign - nMod;
return nRet;
}
Regards,
João Paulo Figueira
Embedded MVP
|
|
|
|
|
|
My MVP profile is now online here[^].
Regards,
João Paulo Figueira
Embedded MVP
|
|
|
|
|
This tool allows you to easily port Microsoft SQL Server and Microsoft Access databases to and from Microsoft SQL Server CE 2.0. Current version is Beta 0.3 and available here[^].
Regards,
João Paulo Figueira
Embedded MVP
|
|
|
|
|
I fell for this one so many times (today included), that I decided to write about it (maybe I won't forget it).
For the "nth" time, I'm writing a small piece of code to completely delete the contents of a list view. I mean, deleting all the items as well as the columns. Here's the masterpiece:
void CMyDialog::ClearDetails()
{
CHeaderCtrl* pHeader;
m_wndListDet.DeleteAllItems();
pHeader = m_wndListDet.GetHeaderCtrl();
if(pHeader)
{
int i,
nColumns;
nColumns = pHeader->GetItemCount();
for(i = 0; i < nColumns; ++i)
pHeader->DeleteItem(0);
}
}
The effect is devastating: after calling this method, the list will never show anything ever again. Why? What is wrong with it? List view columns cannot be directly deleted on the embedded header control, they must be deleted through the list view itself. The solution is simple: use
m_wndListDet.DeleteColumn(0);
instead of
pHeader->DeleteItem(0);
So why do I do this so frequently? Because I have to fetch a piece of information from the header, so my fingers automatically lead me to write the wrong code, instead of the right one.
Wouldn't it be so much easier if MFC allowed us to query the number of list view columns through the CListCtrl class?
Regards,
João Paulo Figueira
Embedded MVP
|
|
|
|
|
I'm preparing a new article on managing BLOBs using the ATL OLE DB Consumer Templates on the Pocket PC. This has been taking me some time because things work a bit differently on the device, especially when using SQL CE 2.0 and its inability of binding columns by reference.
It would be interesting to see what other topics native code developers for the Pocket PC are looking for in this particular area - OLE DB.
|
|
|
|
|
If you read my last article on database development for the Pocket PC (Using the ATL OLE DB Consumer Templates on the Pocket PC[^]), I skipped some necessary changes to the original Microsoft code. These will correct the way the status field is accessed on the CDynamicAccessor data buffer. Locate the first GetStatus method, and change the code to look this way:
bool GetStatus(ULONG nColumn, DBSTATUS* pStatus) const
{
ATLASSERT(pStatus != NULL);
if (TranslateColumnNo(nColumn))
{
*pStatus =
*(ULONG*)(AddOffset(AddOffset((ULONG)_GetDataPtr(nColumn),
m_pColumnInfo[nColumn].ulColumnSize), sizeof(ULONG)));
return true;
}
else
return false;
}
Correct all other address calculations (copy and paste it). Note that the original code is not consistent in calculating the status address.
Regards,
João Paulo Figueira
Embedded MVP
|
|
|
|
|
|
|
|
|
|