I try openning a .mdb file using CDaoDatabase, but at Open() catches an error: Unrecognised database format. I created the database first in MSAcces2007 and saved the file as .mdb, then i installed MSAcces2003 and created the file again, but there's the same error. Does anyone have a clue what's happening?
CString pathDB = "SMACDB\\Transports.mdb";
CDaoDatabase dbTransp;
try
{
dbTransp.Open(pathDB);
CDaoRecordset rs(&dbTransp);
COleVariant var1;
rs.Open(dbOpenSnapshot, "SELECT * FROM Transporturi");
while (!rs.IsEOF())
{
var1 = rs.GetFieldValue(1);
CString val = (LPCTSTR)var1.bstrVal;
g_carRestrict.pCarNmb.AddTail(val);
var1 = rs.GetFieldValue(2);
g_carRestrict.pAllowed.AddTail(var1.lVal);
rs.MoveNext();
}
rs.Close();
dbTransp.Close();
}
catch (CDaoException *pEx)
{
pEx->Delete();
}
Visual C++ 6 uses DAO 3.5 by default which does not support Access 2000 or later formats. To have MFC uses DAO 3.6, change the runtime version number to 6.01.
Suggested reading:
You receive an "Unrecognized database format" error message when you open a database created with Access 2000
Related
Using Octopus Deploy to deploy a simple API.
The first step of our deployment process is to generate an HTML report with the delta of the scripts run vs the scripts required to run. I used this tutorial to create the step.
The relevant code in my console application is:
var reportLocationSection = appConfiguration.GetSection(previewReportCmdLineFlag);
if (reportLocationSection.Value is not null)
{
// Generate a preview file so Octopus Deploy can generate an artifact for approvals
try
{
var report = reportLocationSection.Value;
var fullReportPath = Path.Combine(report, deltaReportName);
Console.WriteLine($"Generating upgrade report at {fullReportPath}");
upgrader.GenerateUpgradeHtmlReport(fullReportPath);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
return operationError;
}
}
The Powershell which I am using in the script step is:
# Get the extracted path for the package
$packagePath = $OctopusParameters["Octopus.Action.Package[DatabaseUpdater].ExtractedPath"]
$connectionString = $OctopusParameters["Project.Database.ConnectionString"]
$reportPath = $OctopusParameters["Project.HtmlReport.Location"]
Write-Host "Report Path: $($reportPath)"
$exeToRun = "$($packagePath)\DatabaseUpdater.exe"
$generatedReport = "$($reportPath)\UpgradeReport.html"
Write-Host "Generated Report: $($generatedReport)"
if ((test-path $reportPath) -eq $false){
New-Item "Creating new directory..."
} else {
New-Item "Directory already exists."
}
# Run this .NET app, passing in the Connection String and a flag
# which tells the app to create a report, but not update the database
& $exeToRun --connectionString="$($connectionString)" --previewReportPath="$($reportPath)"
New-OctopusArtifact -Path "$($generatedReport)"
The error reported by Octopus is:
'Could not find file 'C:\DeltaReports\Some API\2.9.15-DbUp-Test-9\UpgradeReport.html'.'
I'm guessing that is being thrown when this powershell line is hit: New-OctopusArtifact ...
And that seems to indicate that the report was never created.
I've used a bit of logging to log out certain variables and the values look sound:
Report Path: C:\DeltaReports\Some API\2.9.15-DbUp-Test-9
Generated Report: C:\DeltaReports\Some API\2.9.15-DbUp-Test-9\UpgradeReport.html
Generating upgrade report at C:\DeltaReports\Some API\2.9.15-DbUp-Test-9\UpgradeReport.html
As you can see in the C#, the relevant code is wrapped in a try/catch block, but I'm not sure whether the error is being written out there or at a later point by Octopus (I'd need to do a pull request to add a marker in the code).
Can anyone see a way forward win resolving this? Has anyone else encountered this?
Cheers
I recently redid some of the work from that article for this video up on YouTube. I did run into some issues with the .SQL files not being included in the assembly. I think it was after I upgraded to .NET 6. But that might be a coincidence.
Anyway, because the files weren't being included in the assembly, when I ran the command line app via Octopus, it wouldn't properly generate the file for me. I ended up configuring the project to copy the .SQL files to a folder in the output directory instead of embedding them in the assembly. You can view a sample package here.
One thing that helped me is running the app in a debugger with the same parameters just to make sure it was actually generating the file. I'm sure you already thought of that, but I'd be remiss if I forgot to include it in my answer. :)
FWIW, this is my updated scripts.
First, the Octopus Script:
$packagePath = $OctopusParameters["Octopus.Action.Package[Trident.Database].ExtractedPath"]
$connectionString = $OctopusParameters["Project.Connection.String"]
$environmentName = $OctopusParameters["Octopus.Environment.Name"]
$reportPath = $OctopusParameters["Project.Database.Report.Path"]
cd $packagePath
$appToRun = ".\Octopus.Trident.Database.DbUp"
$generatedReport = "$reportPath\UpgradeReport.html"
& $appToRun --ConnectionString="$connectionString" --PreviewReportPath="$reportPath"
New-OctopusArtifact -Path "$generatedReport" -Name "$environmentName.UpgradeReport.html"
My C# code can be found here but for ease of use, you can see it all here (I'm not proud of how I parse the parameters).
static void Main(string[] args)
{
var connectionString = args.FirstOrDefault(x => x.StartsWith("--ConnectionString", StringComparison.OrdinalIgnoreCase));
connectionString = connectionString.Substring(connectionString.IndexOf("=") + 1).Replace(#"""", string.Empty);
var executingPath = Assembly.GetExecutingAssembly().Location.Replace("Octopus.Trident.Database.DbUp", "").Replace(".dll", "").Replace(".exe", "");
Console.WriteLine($"The execution location is {executingPath}");
var deploymentScriptPath = Path.Combine(executingPath, "DeploymentScripts");
Console.WriteLine($"The deployment script path is located at {deploymentScriptPath}");
var postDeploymentScriptsPath = Path.Combine(executingPath, "PostDeploymentScripts");
Console.WriteLine($"The deployment script path is located at {postDeploymentScriptsPath}");
var upgradeEngineBuilder = DeployChanges.To
.SqlDatabase(connectionString, null)
.WithScriptsFromFileSystem(deploymentScriptPath, new SqlScriptOptions { ScriptType = ScriptType.RunOnce, RunGroupOrder = 1 })
.WithScriptsFromFileSystem(postDeploymentScriptsPath, new SqlScriptOptions { ScriptType = ScriptType.RunAlways, RunGroupOrder = 2 })
.WithTransactionPerScript()
.LogToConsole();
var upgrader = upgradeEngineBuilder.Build();
Console.WriteLine("Is upgrade required: " + upgrader.IsUpgradeRequired());
if (args.Any(a => a.StartsWith("--PreviewReportPath", StringComparison.InvariantCultureIgnoreCase)))
{
// Generate a preview file so Octopus Deploy can generate an artifact for approvals
var report = args.FirstOrDefault(x => x.StartsWith("--PreviewReportPath", StringComparison.OrdinalIgnoreCase));
report = report.Substring(report.IndexOf("=") + 1).Replace(#"""", string.Empty);
if (Directory.Exists(report) == false)
{
Directory.CreateDirectory(report);
}
var fullReportPath = Path.Combine(report, "UpgradeReport.html");
if (File.Exists(fullReportPath) == true)
{
File.Delete(fullReportPath);
}
Console.WriteLine($"Generating the report at {fullReportPath}");
upgrader.GenerateUpgradeHtmlReport(fullReportPath);
}
else
{
var result = upgrader.PerformUpgrade();
// Display the result
if (result.Successful)
{
Console.ForegroundColor = ConsoleColor.Green;
Console.WriteLine("Success!");
}
else
{
Console.ForegroundColor = ConsoleColor.Red;
Console.WriteLine(result.Error);
Console.WriteLine("Failed!");
}
}
}
I hope that helps!
After long and detailed investigation, we discovered the answer was quite obvious.
We assumed the existing deploy process configuration was sound. Because we never had a problem with it (until now). As it transpires, there was a problem which led to the Development deployments being deployed twice.
Hence, the errors like the one above and others which talked about file handles being held by another process.
It was actually obvious in hindsight, but we were blind to it as we thought the existing process was sound 😣
I'm using .NET Core 2 with the System.Data.OracleClient package published some weeks ago here: https://www.nuget.org/packages/System.Data.OracleClient/
I can read numbers, dates and normal English characters. But not Chinese. Probably a lot of other non-western characters.
Here's a sample program to illustrate the error:
using System;
using System.Text;
using System.Diagnostics;
using System.IO;
using System.Data.OracleClient;
namespace OracleConnector
{
class Program
{
static void Main()
{
TestString();
return;
}
private static void TestString()
{
string connStr = "Data Source = XE; User ID = testuser; Password = secret";
using (OracleConnection conn = new OracleConnection(connStr))
{
conn.Open();
var cmd = conn.CreateCommand();
cmd.CommandText = "select 'some text in English language' as a, '储物组合带门/抽屉, 白色 卡维肯, 因维肯 白蜡木贴面' as b from dual";
var reader = cmd.ExecuteReader();
reader.Read();
string sEnglish = reader.GetString(0);
string sChinese = reader.GetString(1);
Trace.WriteLine("English from db: " + sEnglish);
Trace.WriteLine("Chinese from db: " + sChinese);
Trace.WriteLine("Chinese from the code: 储物组合带门 / 抽屉, 白色 卡维肯, 因维肯 白蜡木贴面");
}
}
}
}
It outputs this:
English from db: some text in English languageဂ
Chinese from db: ¿¿¿¿¿¿/¿¿, ¿¿ ¿¿¿, ¿¿¿ ¿¿¿¿¿e
Chinese from the code: 储物组合带门 / 抽屉, 白色 卡维肯, 因维肯 白蜡木贴面
As you can see, Chinese characters from normal code works. But not when it comes from the database. Also, the last character in the English text is some messed up thing. I've also tried the corresponding Mono nuget package with the same result.
Anyone have any clue how to fix this?
Edit: Tried adding Unicode=True to the connection string but Chinese characters still doesn't work.
This is a problem with the System.Data.OracleClient DLL. I am having the same problem where 2, 3, or even 4-byte Unicode characters are getting tacked to the end of my strings.
Switching to Mono.Data.OracleClientCore helped slightly, but I still got some odd characters at the end of some strings (Unicode backspace and backslash).
I just tried the following library, and it seems to work for my needs (so far):
https://github.com/ericmend/oracleClientCore-2.0
You will need to re-compile for Windows (change to #define OCI_WINDOWS in OciCalls.cs). Will update this answer if I find that it doesn't continue to work.
Still, I think that we'll have to wait for Oracle to release their .NET Core supported solution for any sort of production ready library.
Please try
Environment.SetEnvironmentVariable ("NLS_LANG",".UTF8");
before creation of the connection-Object.
The System.Data.OracleClient-Implementations uses external Oracle libraries, which assumes (at least on Windows) the ANSI-Charset.
Setting the NLS_LANG-Environmentvariable informs the Oracle-Libs that you want the UTF8-Encoding.
(much) more Details on the NLS_LANG-FAQ-Page:
http://www.oracle.com/technetwork/database/database-technologies/globalization/nls-lang-099431.html
Append ";Unicode=True" to connectionstring and add Environment.SetEnvironmentVariable ("NLS_LANG",".UTF8"); before create connection
string conn = "DATA SOURCE=hostname.company.org:1521/servicename.company.org;PASSWORD=XYZ;USER ID=ABC;Unicode=True"
Environment.SetEnvironmentVariable("NLS_LANG", ".UTF8");
using (DbConnection conn = create_connection(app_conn))
{
//...
}
I'm trying to write a Visual Studio Package that will attach the debugger to a named process.
I am using the following code in my package.
var info = new VsDebugTargetInfo
{
dlo = DEBUG_LAUNCH_OPERATION.DLO_AlreadyRunning,
bstrExe = strProcessName,
bstrCurDir = "c:\\",
bstrArg = "",
bstrEnv = "",
bstrOptions = null,
bstrPortName = null,
bstrMdmRegisteredName = null,
bstrRemoteMachine = "",
cbSize = (uint)System.Runtime.InteropServices.Marshal.SizeOf<VsDebugTargetInfo>(),
grfLaunch = (uint)(__VSDBGLAUNCHFLAGS.DBGLAUNCH_DetachOnStop| __VSDBGLAUNCHFLAGS.DBGLAUNCH_StopDebuggingOnEnd| __VSDBGLAUNCHFLAGS.DBGLAUNCH_WaitForAttachComplete),
fSendStdoutToOutputWindow = 1,
clsidCustom = VSConstants.CLSID_ComPlusOnlyDebugEngine
};
VsShellUtilities.LaunchDebugger(ServiceProvider, info);
However I get the following, unhelpful, error:
Exception : Unable to attach. Operation not supported. Unknown error: 0x80070057.
The code is obviously doing something because if the process has not started I get this error
Exception : Unable to attach. Process 'xxxxxxxx' is not running on 'xxxxxxxx'.
The process is a managed .net 4 process and I am able to attach to it through the VS UI.
For context I am trying to replace a simple Macro I was using in VS 2010 to do the same job but that obviously can't be run in newer versions of Visual Studio.
I found a totally different piece of code, inspited by https://github.com/whut/AttachTo, worked much better to achieve the same result
foreach (Process process in (DTE)GetService(typeof(DTE)).Debugger.LocalProcesses)
if (process.Name.EndsWith(strProcessName,StringComparison.InvariantCultureIgnoreCase))
process.Attach();
I had to use 'ends with' because the process names include the full path to the running exe.
Hi I have A local database named Database1.sdf.
I´m accessing it with following code to insert some data into a table:
public string DoLocalDbCmd(string Command)
{
int NumeroAffetto;
string ConnString = #"Data Source=|DataDirectory|\Database1.sdf";
SqlCeConnection Conn = new SqlCeConnection(ConnString);
SqlCeCommand Comando = new SqlCeCommand(Command, Conn);
Comando.CommandType = System.Data.CommandType.Text;
try
{
Comando.Connection.Open();
NumeroAffetto = Comando.ExecuteNonQuery();
return NumeroAffetto.ToString();
}
catch (Exception ex)
{
return ex.Message;
}
finally
{
Comando.Connection.Close();
}
}
private void button1_Click(object sender, EventArgs e)
{
DoLocalDbCmd cmd = new DoLocalDbCmd();
string cmdex = cmd.RunSqlCmd("insert into TBL_PROVA (BELLO) VALUES ('VERO')");
MessageBox.Show(cmdex);
}
The execution of code happen without errors, I retrieve the number of affected row = 1.
But after if I query the database there is not inserted no row.
Somebody can suggest to me what can be wrong ?
Thankyou in advance
Piercarlo
It is a common scenario when these conditions are all or partially present in your project.
You have a connection string with the DataDirectory substitution
string.
You have a connection on the Server Explorer that point to an SDF
file located in your project directory.
You have the property Copy To Output Directory set to Copy Always
on your SDF file listed in your project items.
When you run the program inside the IDE of VS the SDF file present in your project folder is copied to the Output Directory (BIN\DEBUG) following the setting of Copy To Output Directory and this could result in the overwriting of the file eventually already present in BIN\DEBUG.
You run your code and insert correctly your data into the file in the BIN\DEBUG folder.
You stop your program and checks if the record is present using the Server Explorer and you don't see any new record because you are looking at the file in the Project Folder.
You start a new debug session and the file in the BIN\DEBUG is overwritten again with the empty one.
So... change the property Copy to the Output Directory to Copy Never to stop this copying, change the connection in the server explorer to point to your database in the BIN\DEBUG folder (Or add another one keeping the old one for schema changes and the new one to verify your DML operations)
When I am trying to upload an Image using below code, I am getting following error : java.sql.SQLException: ORA-01460: unimplemented or unreasonable conversion requested
File image = new File("D:/"+fileName);
preparedStatement = connection.prepareStatement(query);
preparedStatement.setString(1,"Ayush");
fis = new FileInputStream(image);
preparedStatement.setBinaryStream(2, (InputStream)fis, (int)(image.length()));
int s = preparedStatement.executeUpdate();
if(s>0) {
System.out.println("Uploaded successfully !");
flag = true;
}
else {
System.out.println("unsucessfull to upload image.");
flag = false;
}
Please help me out.
DB Script :
CREATE TABLE ESTMT_SAVE_IMAGE
(
NAME VARCHAR2(50),
IMAGE BLOB
)
Its first cause is incompatible conversion but after seeing your DB script, I assume that you are not doing any conversion in your script.
There are other reported causes of the ORA-01460 as well:
Incompatible character sets can cause an ORA-01460
Using SQL Developer, attempting to pass a string to a bind variable value in excess of 4000 bytes can result in an ORA-01460
With ODP, users moving from the 10.2 client and 10.2 ODP to the 11.1 client and 11.1.0.6.10 ODP reported an ORA-01460 error. This was a bug that should be fixed by patching ODP to the most recent version.
Please see this