📄 changesknownissues.htm

📁 LLBLGen 1.21 Sourcecode
💻 HTM
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > 
<HTML>
<HEAD>
<META NAME="GENERATOR" Content="Microsoft Visual Studio 7.0">
<TITLE>LLBLGen::Change log and known issues</TITLE>
<link rel="STYLESHEET" type="text/css" href="general.css">
</HEAD>
<BODY>
<br>
<h3>LLBLGen::Change log and known issues</h3>
<h4>Known Issues</h4>
<p>
	<b>Version 1.2.08212002</b><br>
	<ul>
		<li>Generated code is not CLSCompliant due to the fact that the protected members of the abstract
			base class are seen as public methods by FxCop and the compilers, allthough they'll be private
			in any inherited class. This can be fixed easily in the generator but it will result in the 
			breaking of current custom classes which rely on the interface of the current abstract base class
			<i>DBInteractionBase</i>. Therefor, to keep current code working, I decided to move this feature to
			a later version, probably v2.0.</li>
		<li>Weird characters in table names and field names are not handled correctly. F.e. a '$' in a table
			name, will result in non-compilable code. Because it's bad practise to use those kind of characters
			in table names and field names, no fix is provided, allthough v2.0 will probably be handling this
			type of characters better.</li>
		<li>Fields with a Default Value constraint are properly handled by the generated code, however due to
			the nature of T-SQL, the default value is emitted hard-coded in the T-SQL stored procedure. This is
			done to allow users to Insert values for fields with a default value, even if there is a default
			value. When the default value constraint <i>changes</i> for a particular field, the stored procedures for
			the table should be regenerated. The .NET code is not changed. When a default value constraint is
			<i>removed</i> from a field, plus it's not NULLable, the .NET code for that table should be regenerated,
			together with the stored procedures, if the developer wants NULL value checks for the property of
			that field: fields with default value constraints don't have NULL value checks. </li>
		<li>When LLBLGen is started from a network share, or a shared drive, it may crash in a security violation.
			This is due to the fact that the default security settings of a default .NET installation are very strict 
			so that an application which is ran from a network share and which creates an instance of a class, will fail 
			to do so. You can work around this by OR copying the LLBLGen executable (including the manifest) to your 
			local harddrive, OR adjusting the security settings for the LLBLGen assembly to full trust. </li>
	</ul>
</p>
<h4>Change log</h4>
<p>
	<b>Version 1.2.08212002</b><br>
	<ul>
		<li><b>FIXED:</b> When ObjectPooling is selected as a COM+ service, the method <b>CanBePooled()</b> wasn't created in the
			abstract base class.</li>
		<li><b>FIXED:</b> When a field is marked as <i>Excluded</i> and it has a Default Value constraint, LLBLGen will use that
			Default Value instead of the LLBLGen's default for the particular type of the field. </li>
		<li><b>FIXED:</b> When a field has a default value constraint and the field isn't NULLable, an extra ISNULL() 
			check is emitted in the INSERT stored procedure, to prevent the insertion of NULL's and to
			insert the default value instead. The default value is hardcoded in the stored procedure and
			requires a regeneration of the stored procedures when that value changes in the table/field
			definition. It's not very common to use default value contraints with non-NULLable fields 
			however nor are default value constraints changed a lot. </li>
		<li><b>FIXED:</b> Timestamp fields weren't excluded from INSERT and UPDATE queries. This has been fixed. Also,
	        the wrong default value for Timestamp fields has been removed: it's not used anymore.</li>
		<li><b>FIXED:</b> ADO.NET contains a bug which doesn't allow a precision for SqlParameter which is larger than 38. However, 
			SQLServer's float datatype has a precision of 53. Generated code contains this precision
			of 53 and fails at runtime. LLBLGen now contains a workaround for this bug and limits
			the precision to 38. When MS fixes this bug (if ever), this workaround will be removed.</li>
		<li><b>FIXED:</b> In the frmDirPicker code, when the start directory supplied doesn't exist, LLBLGen will crash.
	        This has been fixed: the first root node (probably 'A:') will be selected instead.</li>
		<li><b>FIXED:</b> When the fonts are enlarged in windows, the gui sizes are not, which means that the texts on
			the controls look horrible. This is fixed. It appears to be a bug in the .NET windowsforms
			renderer: when a tab page is added at runtime, the controls on it aren't auto-resized to meet
			the requirements of the large fonts. This is avoided now, by adding all tab pages at the start
			of the program, but disabling all controls on the tab pages except the controls on the connection
			tab.</li>
		<li><b>ADDED:</b>Added a known issues chapter to the documentation, plus changed the font into verdana which is much
	        more readable than Tahoma. </li>
	</ul>
</p>
<p>
	<b>Version 1.2.08112002</b><br>
	<ul>
		<li><b>FIXED:</b> Fixed some bug in the docs and a bug in the INSERT stored proc generator for SQLServer 7</li>
	</ul>
</p>
<p>
	<b>Version 1.2.08022002</b><br>
	First v1.2 release.
</p>
<div align="right" class="SmallFontTOC">
	<hr size="1" width="60%" align="right">
	LLBLGen v1.2 documentation. &copy; 2002 <a href="http://www.sd.nl/" target="_blank">Solutions Design</a>
</div>
<br><br>
</BODY>
</HTML>
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -