Losing Oracle user name and password

I have written a simple SQL Server 2005 package to pull some data from Oracle (using ODBC) and pumping it into SQL Server. When I run it from the server in debug mode in VS it works fine. When I schedule the job it errors out with "ora-01005: null password given; logon denied." The password is there. Has anyone experienced this? Is there a security setting somewhere preventing me from saving passwords? Is there a work around? Thanks.

Passwords are not saved in a package unless in an encrypted format. Check the ProtectionLevel property of your package to set this up.

-Jamie

|||Thanks, that was it.sql

Losing odbc connection on install

We have a system which uses an ODBC connection to connect to SQL Server 2000
for Ceridian Prism--an application for HR departments. Now we are installing
a VB.Net application which uses MSDE (SQL 7). The problem is that for some
reason we are losing the original ODBC connection to 2000 when we install
MSDE. Now I realize that installing MSDE 2000 may help this issue, however
we really need to use SQL 7 for now. Does anyone have any ideas of what
might be causing the loss in the connection? Is the SQL 7 install
overwriting something that the ODBC needs for the 2000 connection? Is it
something with named instances? We are using the standard MSDE installation
from Microsoft.
Thanks.
My guess is that the MSDE 7 installation is installing an older version of
MDAC which is not ADO.Net compatible. It could also be an issue with named
instances as earlier version of MDAC (pre 2.5 I think) did not support named
instances.
Jim
"LisaConsult" <lisaconsult@.online.nospam> wrote in message
news:81EA76DC-A07B-4982-B9F2-CD31ACE1F0B0@.microsoft.com...
> We have a system which uses an ODBC connection to connect to SQL Server
> 2000
> for Ceridian Prism--an application for HR departments. Now we are
> installing
> a VB.Net application which uses MSDE (SQL 7). The problem is that for
> some
> reason we are losing the original ODBC connection to 2000 when we install
> MSDE. Now I realize that installing MSDE 2000 may help this issue,
> however
> we really need to use SQL 7 for now. Does anyone have any ideas of what
> might be causing the loss in the connection? Is the SQL 7 install
> overwriting something that the ODBC needs for the 2000 connection? Is it
> something with named instances? We are using the standard MSDE
> installation
> from Microsoft.
> Thanks.
|||Thanks for your response. Actually, we know that it is somehow SQL Server
related and not MDAC because once we uninstalled Server Manager and MSDE, the
connection worked fine again. As an aside, if they needed MDAC, we installed
2.6, but as I said, I don't believe this was the issue. Any other thoughts?
Thanks
"Jim Young" wrote:

> My guess is that the MSDE 7 installation is installing an older version of
> MDAC which is not ADO.Net compatible. It could also be an issue with named
> instances as earlier version of MDAC (pre 2.5 I think) did not support named
> instances.
> Jim
> "LisaConsult" <lisaconsult@.online.nospam> wrote in message
> news:81EA76DC-A07B-4982-B9F2-CD31ACE1F0B0@.microsoft.com...
>
>
|||Oops, my mistake, this app is actually still a VB6 app.
"LisaConsult" wrote:

> We have a system which uses an ODBC connection to connect to SQL Server 2000
> for Ceridian Prism--an application for HR departments. Now we are installing
> a VB.Net application which uses MSDE (SQL 7). The problem is that for some
> reason we are losing the original ODBC connection to 2000 when we install
> MSDE. Now I realize that installing MSDE 2000 may help this issue, however
> we really need to use SQL 7 for now. Does anyone have any ideas of what
> might be causing the loss in the connection? Is the SQL 7 install
> overwriting something that the ODBC needs for the 2000 connection? Is it
> something with named instances? We are using the standard MSDE installation
> from Microsoft.
> Thanks.
|||I still think that it is a problem with the data connection layer and not
SQL Server. Have you tried installing MDAC 2.8 after MSDE 7 is installed.
Jim
"LisaConsult" <lisaconsult@.online.nospam> wrote in message
news:2271E92F-AFE5-4C14-A8FA-2A05326227B6@.microsoft.com...[vbcol=seagreen]
> Thanks for your response. Actually, we know that it is somehow SQL Server
> related and not MDAC because once we uninstalled Server Manager and MSDE,
> the
> connection worked fine again. As an aside, if they needed MDAC, we
> installed
> 2.6, but as I said, I don't believe this was the issue. Any other
> thoughts?
> Thanks
> "Jim Young" wrote:

Loosing ODBC connection

Hi all,

We recently converted an application from accecc97 to access2003.
We used to have 2 databases : 1 with all and only the data (axelD.mbd), 1 with all the forms, query's, ... (axelP.mdb)

We replaced the data (axelD.mdb) with an MSDE database, through UPSIZE and so on. That all worked fine.
This database is placed on the dataserver (DATA1), the converted programm is on the FRONT2 server (FRONT1 stil usess access97 until conversion is totally ready).

We are able to connect to the MSDE by using ADODB recordsets.
We are also perfect able to link the MSDEtables in our axelP.mbd database

We started to test some heavier parts of our application and started to get the following error:

"ERROR 3151"
"ODBC--connection to 'JOROSOFT' failed"

Nothing more.

This happened in a quite complex routine, whitch updates a lot of records, several times and so on.
We could reproduce the same error when executing the following code:

Public Function TestBestellingen()
Dim sql As String
Dim intervalset As DAO.Recordset
Dim planset As DAO.Recordset
Dim tellerke

x = Opendatabases()
tellerke = 0
sql = "Select bestelnummer from vkpbestellijn where bestelnummer > 100000"
Set planset = Db_AxelP.OpenRecordset(sql, dbOpenDynaset)
Do While Not planset.EOF
tellerke = tellerke + 1
Debug.Print tellerke & " - " & planset!Bestelnummer & " --> " & IsKlantStof(planset!Bestelnummer)
planset.MoveNext
Loop
End Function

Function IsKlantStof(p_bestelnummer)
Dim sql As String, rst As DAO.Recordset
Dim hulp_klantstof As Boolean

hulp_klantstof = False
x = Opendatabases()
sql = "select klantstof from vkpbestellijn where bestelnummer = " & p_bestelnummer
Set rst = Db_AxelP.OpenRecordset(sql, dbOpenSnapshot)

With rst
Do While Not .EOF
If !KlantStof = True Then
hulp_klantstof = True
.MoveLast
End If
.MoveNext
Loop
End With
rst.Close
Set rst = Nothing
IsKlantStof = hulp_klantstof
End Function

Function Opendatabases()
If Db_AxelP Is Nothing Then
Set Db_AxelP = DBEngine(0)(0)
End If
End Function
I know this code makes no sence in a real-time environment, but it was to reproduce the error.
This code basically runs trough a 30.000 records and does a little check for certain fields
After 1981 records we get the above error.
(sometimes after 1979 or 1980 or 1982 records)

1977 - 100859 --> True
1978 - 100860 --> True
1979 - 100860 --> False
1980 - 100861 --> True
1981 - 100861 --> True

"vkpbestellijn" is a table that is linked in the AxelP.mdb trough an ODBC connection.
We get the same error (and after 1981 times) if I change the where to a totally other range of "bestelnummer"

I have installed the latest patches of Jet 4.0, MSDE-server, ...

I've been searching the internet for abour 3 days now, and just cant even find the smallest clue what could make this happen.

I hope someone here has an idea.
If you need more details, just ask.

tia,
Axel.

P.S. I'm from Belgium, so my english aint "correct to the point".MSDE auto closes when the last user disconnects.

ALTER DATABASE MyDB AUTO_CLOSE OFF might take care of this.|||I tried that, but it didn't changed a single thing.

The exact same problem still occurs. :eek: :eek:

Getting desperate here. :o|||Is there no one around who recognises the problem or came across that problem?

I've tried playing with the Query governor, but that didn't changed a single thing.

The strange thing is that when i try the same code on a identically server that is in use by users, i have it less frequent.
It looks like the MSDE server cant keep up with all the quesry's executed. And when the server has more users working, it has enough time to release some things.

does that makes sence top anyone?

Loose ODBC conection

I am very new to all this

I have a access databse wich uses a ODBC conection to mysql server. I
can open the and run the database find but if i leave the dadabase
loaded but do not use it when i go back to it is has lost the
conection and i need to close the databse and reopen it

If there a way to make sure i alwasy have a coenction

Thanks(S.Dickson@.shos.co.uk) writes:

Quote:

Originally Posted by

I am very new to all this
>
I have a access databse wich uses a ODBC conection to mysql server. I
can open the and run the database find but if i leave the dadabase
loaded but do not use it when i go back to it is has lost the
conection and i need to close the databse and reopen it
>
If there a way to make sure i alwasy have a coenction

That seems like an Access problem to me. Maybe you should ask in an
Access newsgroup.

Do you use MySQL or is that just a typo? This news group is for
MS SQL Server, and not MySQL.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx

Looking for SQL-Server ODBC parameters

I've been browsing all over the net, through technet and MSDN as well, all to no avail.

I'm looking for the parameters I can use with SQL-Server drivers of MDAC 2.7 when using dbcconfig in scripts.

E.g. with mysql you can do a line "DSN=Test;Description=Test Odbc DSN;Server=Test_server;user=stars"

Using odbcconf configsysdsn "SQL Server" "DSN=Test DSN;Description=For stars;User=Stars" I get the error "Unable to create a data source name for the "sql-server" driver, drivers configdsn, config driver or configtranslator failed.

If i remove everything but the DSN name, it works, so I must be getting the parameters wrong. But exactly where, I'm not sure..

Thanks for your help!

FlixFirst of all, you should consider to use the native SQL Server OLE DB provider, instead of the ODBC provider. Microsoft declared this provider already obsolete.

Secondly, you reporting two different things: Your MySQL line specifies the ConnectionString as required for the ODBC OLE DB provider. Your SQL Server line, however, does the same, but you are trying to mix that with ODBCConfig.

So, I'm not sure what you want to achieve:

1) specify a DSN-based connection string
2) dynamically define a DSN
3) specify a DSN-less connection string

For 1) and 3) look here (www.able-consulting.com/MDAC/ADO/Connection/OLEDB_Providers.htm#OLEDBProviderForODBCDatabases)|||The old ODBC providor is merely contained to an older system not yet phased out. Based on a SQL-Server 6.5. As all programming ressources on that system has died out, its merely a question of time before an entirely different system is set in place.

My problem (literally) is to keep the system alive as is, and in this case it is to define a DSN through loginscripts using ODBCconfig, as I would otherwise have to churn around with 150 machines creating a host of different DSN's.

In my testing case I am able to give a MySQL DSN more specific arguments using ODBCconfig as opposed to the SQL-Server DSN. Namely which user the DSN should use, and what DB to access... and I can't see the sense in that, as I need to specify user and DB as you would normally do using your ODBC administrating tool.

Hope this clarify's my situation just a whee bit.

Thanks,

Flix|||Okay, if I understand you right, your primary problem isn't to generate a DSN, but to connect via ODBC? Why don't you follow my point 3): use an DSN-less ODBC connection.|||That would require a recoding of this ancient Access 95/97 and SQL 6.5 based system, which is practically like sticking your hand into a wasp-nest. Or do I read the stuff wrong?

Its the database front-end that needs the system DSN's, and in the database there are hordes of linked tables, queries and code all built up against the presence of the system DSN's.

Recoding of the app is pretty much out of the question, as it is destined to be replaced within 6 - 12 months.. so I just need a way to distribute the system DSN to our workstations, in which case I chose odbcconf as it could be called from the login-script.

Cheers, Flix|||Okay, this (http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q171/1/46.ASP&NoWebContent=1) should help you.