I'm from Brazil and this my first time here.
I've always used MySql5xx in my ERP in VB.NET using ODBC connection. It always worked very well but now I need to use the "With Recursive" clause in the query and isn't support in mySQL lower then 8.
The problem is that my app simply crashes after some few interactions with MySQL8, using the Odbc Driver, without any other messagem then just
"A problem caused your program to stop working correctly. Windows will close the program and notify you if a solution is available"
I've already tried to install mySql8 in Windows10, Srv2012, Srv2016 but the problem is always the same and I'm unabled to use it.
If someone has any tip, any sugestion, will be very welcome.
Above are the mySql8.ODBC connection strings I'm using
Dim sOdbcAnsi_MySql8_va As String = "DRIVER={MySQL ODBC 8.0 ANSI Driver};Server=DELLSRV-2016;Port=3308;DataBase=mydb;UID=root;PWD=xxxxx"
Dim sOdbcAnsi_MySql8_va As String = "DRIVER={MySQL ODBC 8.0 Unicode Driver};Server=DELLSRV-2016;Port=3308;DataBase=mydb;UID=root;PWD=xxxxx"
And here is the CNN.String that works well with mySql5xxx
Dim sOdbc_MySql51_va As String = "DRIVER={MySQL Odbc 5.1 Driver};Server=LocalHost;DataBase=madepratico_va;UID=root;PWD=1q2w3e4r"
Thanks for now
Related
I am upgrading old system that runs under Windows XP to Windows 10.
One of the application have been developped in MS Access XP linked to an Oracle Database (Oracle 9i - instant client ODBC driver 32bit).
My computer is in French, MS Access is in french.
When I run a SQL line :
SELECT LIST_NAME FROM WZ_LISTS_HD WHERE LIST_REL1 = 'Produit'
I get the following result :
Summary Access vs SQL Explorer Windows 10 vs Windows XP
In Windows 10 (access), I get a #Deleted for each record with a special character (in this case "è" or "é"). I try with an homemade SQL Explorer and I get no #Deleted but I don't have the special character.
In my old system (Windows XP) with my SQL explorer, I get the complete recordset with special characters.
Anyone have an idea how to work this out? Most of post about #Deleted is suggesting each database corrupt or "needed for db compaction". In my case, I can get the records with my old system without a problem. There is users working with the database everyday. Hence, database is ok.
"Compacting database" makes no sense since I don't use a mdb (Access main db files).
I tried changing my windows keyboard and language feature. Didn't work.
Once last thing, I've done the same upgrade (Windows XP -> Windows 7) for some user under Windows 7. Worked like a charm. No #Deleted record. It seems to be related to how Windows 10 handles language.
This is the TNSNAMES.ORA File content.
SYNDATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = serveur-oracle)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = oracle6)
)
)
The ODBC information goes as follow :
ODBC Screenshot
Here is the part of code that call the SQL request :
VBA Code
Any ideas are welcomed.
To use passthrough queries instead of normal recordsets:
Dim qd As DAO.QueryDef
Set qd = CurrentDb.CreateQuerydef("", "SELECT LIST_NAME FROM WZ_LISTS_HD WHERE LIST_REL1 = 'Produit'")
qd.Connect = CurrentDb.TableDefs("LIST_NAME").Connect 'Reuse the connect
Dim rs As DAO.Recordset
Set rs = qd.OpenRecordset(dbOpenSnapshot, dbReadOnly) 'Minimal chance to see weird things with snapshots
When using passthrough queries, the SQL needs to be valid for Oracle (PL/SQL) and not for Access. They are executed directly on the backend database, limiting the opportunity for Access to do weird stuff. You do need to use UPPER instead of UCASE, for example.
I have dbext installed into gVim - the plugin menu is visible and the help file are accessible; just not helping at the moment!
Suspect it is a connection string problem. I have the following in _vimrc:
" Microsoft SQL Server
let g:dbext_default_profile_WH = 'type=SQLSRV:user=profileName:passwd=profilePassword:dsnname=SQLOLEDB.1:srvname=imsname'
Is this correct?: dsnname=SQLOLEDB.1
Here is my working connection string configuration
let g:dbext_default_profile_mydb = 'type=SQLSRV:user=sa:passwd=password:srvname=localhost\SQLEXPRESS:dbname=mydb'
It seems that only difference between two configuration strings DNS part so it might be DNS problem as you mentioned.
I just started working with an application that I inherited from someone else and I'm having some issues. The application is written in C# and runs in VS2010 against the 3.5 framework. I can't run the application on my machine to debug because it will not recognize the way they referenced their parameters when writing their DB queries.
For instance wherever they have a SQL or DB2 query it is written like this:
using (SqlCommand command = new SqlCommand(
"SELECT Field1 FROM Table1 WHERE FieldID=#FieldID", SQLconnection))
{
command.Parameters.AddWithValue("FieldID", 10000);
SqlDataReader reader = command.ExecuteReader();
...
If you will notice the "parameters.AddWithValue("FieldID", 10000);" statement does not include the "#" symbol from the original command text. When I run it on my machine I get an error message stating that the parameter "FieldID" could not be found.
I change this line:
command.Parameters.AddWithValue("FieldID", 10000);
To this:
command.Parameters.AddWithValue("#FieldID", 10000);
And all is well... until it hits the next SQL call and bombs out with the same error. Obviously this must be a setting within visual studio, but I can't find anything about it on the internet. Half the examples for SQL parameter addition are written including the "#" and the other half do not include it. Most likely I just don't know what to search for.
Last choice is to change every query over to use the "#" at the front of the parameter name, but this is the transportation and operations application used to manage the corporation's shipments and literally has thousands of parameters. Hard to explain the ROI on your project when the answer to the director's question "How's progress?" happens to be "I've been hard at it for a week and I've almost started."
Has anyone run into this problem, or do you know how to turn this setting off so it can resolve the parameter names without the "#"?
Success! System.Data is automatically imported whenever you create a .NET solution. I removed this reference and added it back to make sure that I had the latest version of this library and that fixed the issue. I must have had an old version of this library that was originally pulled in... only thing I can figure.
Its handled by the .NET Framework data providers not Visual Studio.
It depends on the data source. Look here:Working with Parameter Placeholders
You can try working with System.Data.Odbc provider and using the question mark (?) place holder. In thios case dont forget to add the parameters in the same order they are in the query.
I'm using an application called Logi info. it requires a connection string to my oracle database. the connection works fine but in order to configure the connection to recive ref cursors from the database, I apparently need to add PLSQLRSet=1 to the end of the string. when I do that I recieve an error "invalid connection string"
Here is my connection string without plsqlrset=1
Data Source=SID; User Id=username; Password=password;
My concern is that PLSQLRSet=1 might be .NET paramater only. Can anyone shed some light on the issue.
Thanks
It appears that the PLSQLRset option is a feature of the OraOLEDB provider (per http://download.oracle.com/docs/cd/B10501_01/win.920/a95498/using.htm).
Therefore I would guess that you have to add Provider=OraOLEDB.Oracle to the connect string -- as shown in the screenshot on the page you linked to -- in order to use this option.
I am working on some small project for the local firm and the following code runs fine on my machine, but it produces errors on their server. Currently I don't have access to that server, and this is not a field that I know a lot about, so I have to ask you guys.
The page is written in the classic ASP (javascript for scripting).
The logic goes like this:
conn.Open("myconnection");
bigQuery = "...";
rs = conn.execute(bigQuery);
while (!rs.eof) {
...
smallQuery = "..."
rssmall = conn.execute(smallQuery);
...
rssmall.close();
...
rs.movenext();
}
rs.close();
conn.close();
As I said this runs fine on my machine, but it returns some error (the worst thing is that I don't even know what error) on company's server if bigQuery returns more than ~20 rows. Is there something wrong with my code (this really isn't my field, but I guess it is ok to gather data in the loop like this?), or is there something wrong with their IIS server.
Thanks.
edit:
More info:
It 's Access database. Everything is pretty standard:
conn=Server.CreateObject("ADODB.Connection");
conn.Provider="Microsoft.Jet.OLEDB.4.0";
conn.Open("D:/db/testingDb.mdb");
Queries are bit long, so I wont post them. They are totally ordinary selects so they aren't the issue.
I had a legacy Classic ASP application which I inherited that was very similar (big queries with other queries running within the loop retrieving the first query's results) that ran fine until forty or more records were returned. The way I "solved" the problem was to instantiate another connection object to run the other query. So using your pseudo code, try --
conn.Open("myconnection");
conn2.Open("myconnection")
bigQuery = "...";
rs = conn.execute(bigQuery);
while (!rs.eof) {
...
smallQuery = "..."
rssmall = conn2.execute(smallQuery);
...
rssmall.close();
...
rs.movenext();
}
rs.close();
conn2.close();
conn.close();
What server are they actually running?
Most newer versions of Windows Server don't actually come with the Jet 4.0 driver for 64 bit at all so you can't use an access database with that driver if your app runs as a 64 bit app. You can try running as 32 bit which might solve the problem.
There is an alternative driver packaged as an office component which may be an option.
Try writing a simple test page that literally opens and closes the database connection like so:
<%
Dim conn
Set conn = Server.CreateObject("ADODB.Connection")
conn.Provider = "Microsoft.Jet.OLEDB.4.0"
conn.Open("D:/db/testingDb.mdb")
Response.Write("Database Opened OK")
conn.Close()
%>
Run this on the production server and if you see Database Opened OK then you'll know it's definitely the query rather than the database causing the issue.
If you get an error trying to open the database then you need to changed to using the newer driver or try the app in 32 bit mode
In the case that it is the query causing the issue then it may be that you'll need to use the various additional arguments to the Open() method to try using a different cursor (forward only if you only need to iterate over the results once) which will change how ADODB retrieves the data and hopefully mediate any performance bottleneck related to the query.
Edit
If you want to try debugging the code a bit more add the following at the start of the file. This causes the ASP script processor to continue even if it hits an error
On Error Resume Next
Then at intervals throughout the file where you expect an error might have happened do
If Err <> 0 Then
Response.Write(Err.Number & " - " & Err.Description)
End If
See this article from ASP 101 for the basics of error handling in ASP and VBScript