I have a new server with the same Classic ASP code connecting to same SQL Server 2000 database with the same connection string yet it seems to be pulling data out of the database differently now. Specifically there is a custom encryption function which creates special characters (non-ASCII) and stores them in a VARCHAR field. (This is legacy code.) Since nothing has changed except the web server it has been hard to diagnose this problem.
Is there some setting that would control the database driver which would allow this data to come out of the database? It seems the character set is not treated the same with the new server as it was with the old server. Is there something I can change in the ODBC driver settings?
The server version change is from IIS 6 to IIS 7.5. The new server obviously also has new ODBC driver versions.
Any help is appreciated?
I suspect something to do with Locale rather than anything else. However I don't understand Locale. :-(
If it is a stored proc, a quick-fix might be to change the data type on the DB parameter/column to NVARCHAR. With ASP it will be unicode BSTR values in the application anyway, so moving the conversion into the database may make it easier to control, if necessary by specifying a collation to use for the conversion.
If you have the ASP code you could also edit the select to say cast(password as nvarchar(50)) as password or whatever to achieve the same result.
Related
I have a problem..
I work with ASP.NET and After I add a data (Arabic language) to my form via the browser it added to the SQL Server Management Studio like this (???????) even when I retrieve the data entered by the browser, Although there is no problem when I add my Arabic data via SQL Server Management Studio direct.
(there is no problem with English data)
Somewhere along the way your changing the charactertype to something else, that is probably Standart ascii.
It is impossible to know where exactly since we don't have hany information about that, but I would guess that in your Backend things are messed up, try commenting out your code and just echoing the values to see if they are already wrong at that stage.
Maybe change the Stringtype to utf-16
That should support any chars you throw at it
I am busy developing my own application, it uses a sql server database and it is connected through an entity framework. I use store procedures to insert, update, delete, select from my database.
The app works perfect on my machine even when I publish it. But my problem comes in when I try to install the app to my friend’s computer. It crashes and does not start because it cannot connect to the database.
Is there a way to publish my app with the database, without importing all the tables, store procedures and database into my friend’s pc? I just want to make it so the user just has to install the app and it works.
Your app relies on the db to work, so if you want to put it on your friends PC then you need to make the DB available somewhere, whether it be a local copy or a copy stored on a server somewhere running SQL.
How are you storing your connection string? Is it hard coded in the app or are you utilising the app.config file? To do what you're trying to do you'll need to put the connection string into the app.config file, so you can change it depending on the installation.
either that or
if you want to run your app without data, put a demo flag or something into the app.config file. Put some code into your app to check this value, if it's true then bypass the SQL code and maybe supply some demo data which is hard coded.
Does this make sense?
You could use SQL CE, but you may find it a little more difficult to 'design' your database in it if you are more used to working in SQL Server.
Have you considered SQL Server Express as an option?
On the connection string issue, you can now get the data connection wizard that Microsoft use in Visual Studio via Nuget; this makes adding a way to dynamically configure connection strings on your clients machine much easier.
Lastly, connection strings for the entity framework are different from standard SQL connection strings. Make sure that you clearly understand the differences before you start trying to configure them programmatically. Julie Lerman's excellent book on the Entity Framework explains the differences well.
As the title indicates I have an MVC 2 Application running on Server 2003. So, I have IIS6 and a SQL Server 2005 instance on another machine that I am connecting to.
Here's the scoop:
--I have done the wildcard hack to get the MVC routing to work and the site loads correctly.
--I can read information from the database and everything displays fine. (So MVC is working)
--I am using Linq to SQL.
--When I attempt to update data in the database I get an internal server error.
--The website runs correctly and will read and save information to the same SQL server instance when running from Casinni or IIS Express on my development machine.
Some other possibly useful information: I am using Windows Integrated Authentication (the website sees me as the user correctly), the app pool on IIS is running as a user who has both read and write access to the database. I also currently have anonymous authetication turned off, but turning it on caused no change.
Any ideas would be really appreciated. I feel like it's something really simple that I am just missing.
So after long hours on the phone with MS tech support here is the answer:
So if you have a database that contains two tables, both with automatic integer primary keys, and a relationship exists between a unique char field in one and a non-unique char field in the other, inserting new rows into the second table leads to invalid case exception. This exception does not happen when calling to the database from Cassini, IIS7.5 Express or IIS 7.5 but does from IIS.6.0.
I restructured the database to avoid this design architecture and the problem was resolved.
I've written my website using ASP.NET MVC and SQL Server (used a SQL Server instance which ran locally on my machine).
I'm about to upload my site to a hosting provider. However, his DB works under MySQL. I don't care about the data already in the DB itself. It's mostly mock data and a few tables which I don't mind rewriting. But how do I go about the transition from SQL Server to MySQL? How does this influence my queries inside my code? is it the same code syntax? Will I have to recreate the table definitions? In my project I used LINQ to SQL.
Am I forced to look for a host with SQL Server capabilities (i.e. licenses)? (I hope not...)
Thanks!
You may be able to transition smoothly, but I greatly doubt this will be the case.
The differences are many and whether you could depends on what features you used when developing.
If you kept to one of the standards, you may be in luck.
See a comparison sheet on wikipedia.
In regards to the Linq aspect of your question - you should be able to use a Linq provider for MySql instead of MSSql without a problem.
Here is a link to one: http://code2code.net/DB_Linq/
If you do decide to go with the MySql hosting, I suggest you test all aspects of you application to ensure they are working as expected.
LINQ to SQL works with MS SQL Server only...so if you want to keep using it, you need to find a host with a MSSQL database.
I am trying to migrate from Access Database to SQL server database. Do I need to make changes (for saving, reading, deleting etc. data) to my code as well?
I understand I need to change connection but what about code?
Thanks
Furqan
For the most part, Access SQL Queries are very similar to SQL Server Queries. Therefore, unless you're using Access-specific constructs such as Val, CInt, etc in your queries, you can safely migrate to SQL Server.
It is recommended though, that you thoroughly test the program after migration lest you run into 'strange' errors.
I'm sure the conversion will require some time and troubleshooting. For one, Access through version 2007 uses VBA for the back-end code and SQL Server's programming is quite different from VBA. Developer's transitioning from Visual Basic 6 (very similar to VBA) to VB.NET ran into quite a few challenges.
Also, keep in mind that SQL Server is best used as the back-end storage engine. The user interface is typically written in a .NET language using Visual Studio. SQL Server (at least through 2005 -- I haven't used 2008) doesn't have user interface components like a File Open dialog box.