String z aplikacji zmieniany na notację wykładniczą przez SQL Serwer

Hej,

Moja aplikacja odczytuje dane tekstowe z excela. Dane wypełniam w tabeli string[] data.

Ale w momencie wypełniania procedury i strzale do bazy, dane tekstowe zawierające liczby są zapisywane w postaci notacji wykładniczej

np: "1000000" na bazie w kolumnie nvarchar (255) przyjmuje postać 1e+006

podejrzewam jakieś globalne ustawienia sql , które pozwalają dowolnie interpretować przychodzące dane i w pomencie przekroczenia 6 znaków w liczbie zamiania zapis na ww notację.
Dla mniejszych cyfr takiego problemu nie ma.

Ok a gdzie jest pytanie?

A jeśli pytaniem jest czemu się wygląd liczb zmienia to ja bym obstawiał jednak aplikację gdy dochodzi do konwersji liczna -> string. Co to za aplikacja?

MVC na .net6.

A pytanie to: Jak powstrzymać tą konversję. Chciałbym, żeby string był w całości zapisywany jako tekst do kolumny nvarchar.
Zapomniałem jeszcze dodać, że kiedy kolumnę zmieniłem z nvarchar(255) na ntext liczby w stringu zapisywały sie poprawnie. Ale ntext zabiera zdecydowanie za dużo miejsca.

kod jak zapisujesz do bazy

wg mnie jest to problem odczytu z excela.... trzeba zmienić format liczby w kolumnie/komórce, a potem dopiero odczytać wartość

Komórki excel są tekstowe. Odczytuje je za pomocą IExcelReader do string[] data.

Metoda voidowa zapisu przyjmuje "string[] data."
zapisuje dane poprzez DataTable dt = new DataTable(); i SqlDataAdapter

SqlCommand procedureCommand = new SqlCommand(procedureString, connection);
procedureCommand.CommandType = CommandType.StoredProcedure;

procedureCommand.Parameters.AddWithValue("@_deklarValue", data[54]); //do tego momentu dane są w formacie "1000000"

SqlDataAdapter adapter = new SqlDataAdapter(procedureCommand);
adapter.Fill(dt);

A co masz w tej StoredProcedure? Jakiego typu jest parametr 54 (tam naprawdę jest tyle parametrów?) i i czy w środku nie masz jakiejś niejawnej konwersji z numeric na string.

S4t napisał(a):

A co masz w tej StoredProcedure? Jakiego typu jest parametr 54 (tam naprawdę jest tyle parametrów?) i i czy w środku nie masz jakiejś niejawnej konwersji z numeric na string.

StoredProcedure to domyślna metoda

a parametr to komórka z tablicy string[] data

#region zestaw System.Data.Common, Version=6.0.0.0, Culture=neutral, PublicKeyToken=************
// C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\6.0.4\ref\net6.0\System.Data.Common.dll
// Decompiled with ICSharpCode.Decompiler 6.1.0.5902
#endregion

namespace System.Data
{
    //
    // Podsumowanie:
    //     Specifies how a command string is interpreted.
    public enum CommandType
    {
        //
        // Podsumowanie:
        //     An SQL text command. (Default.)
        Text = 1,
        //
        // Podsumowanie:
        //     The name of a stored procedure.
        StoredProcedure = 4,
        //
        // Podsumowanie:
        //     The name of a table.
        TableDirect = 0x200
    }
}

Parametrów jest dużo więcej :D excel jaki musi obsłużyć apka jest spory. Dlatego też używam szablonu z już sformatowanymi komórkami, żeby użytkownik miał mniej miejsca na błąd

Chodzi o to, żebyś pokazał tego SQL, który robi Inserta do bazy

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

ALTER procedure [dbo].[uspInsertImport]
@_deklarValue as nvarchar(255)

as
begin
INSERT INTO ImportCalcData
      (
		 deklarValue
	)
VALUES
    (
		@_deklarValue
		
	)
end

Jak nic nie mieszasz to tu nie ma gdzie zajść jakaś konwersja i problemem jest w excelu jak sugerował @areklipno.

No też to podejrzewaliśmy, ale po wykonaniu pracy przez IExcelReader, mam prawidłowo wypełnioną tablice stringów.
Więc od tego momentu co może być nie tak z excelem?

Jaki masz format komórki w Excelu? (ogólne, liczbowe, tekstowe, czy niestandardowe "0")

Jak już pisałem wcześniej tekstowe. Ustawiony mamy nawet szablon ze sformatowanymi komórkami, żeby użytkownik miał mniejsze pole do błędu.

Ale nadal nie widzę związku, bo po tym jak IExcelReader odczytuje excela i przekłada dane do

string zmienna

To one nie są już tekstem?

AdamAdam_MF napisał(a):

Jak już pisałem wcześniej tekstowe. Ustawiony mamy nawet szablon ze sformatowanymi komórkami, żeby użytkownik miał mniejsze pole do błędu.

Ale nadal nie widzę związku, bo po tym jak IExcelReader odczytuje excela i przekłada dane do

string zmienna

To one nie są już tekstem?

Jeśli nie sprawdziłeś debugerem to ... kiepsko

jedyna "prawdziwa" komórka stringowa w excellu, to zaczynająca się od cienkiego aportofu tj '1000000 Wielokrotnie naprawiałem dzieła różnych guru excella, no cóż, nie wiedzieli o tym ...
Wszystko inne jest "może", może stać się datą, liczbą w formacie naukowym itd

(podobnie jak wielu w wątku, absolutnie głosuję, że zmiana zachodzi w środowisku excellowym - nic potem tej zmiany nie dokonuje)

Coś mi się nie zgadza, skoro z .net wywołujesz i podstawiasz parametry stringowe, do procedury wkładasz nvarchar i używasz go w insercie, to pytanie brzmi jakiego typu pole jest w tabeli?

Skoro przekazujesz inta o wartości 1000000 do procedury przyjmującej nvarchar i to zmienia reprezentację na stringa 1e+006 to może po prostu nie przekazuj innego typu tylko zrób jawną konwersję:

procedureCommand.Parameters.AddWithValue("@_deklarValue", data[54].ToString());

i problem z głowy. A jeśli data[54] już wcześniej zawiera stringa 1e+006 to problem nie jest po stronie sql i w ogóle zły dział

A ja mam propozycję, abyś zrobił 2 testy:

• import z pliku csv (zapis do csv tego pliku excel) i wpis do bazy
• import z pliku excel i zapis do pliku tekstowego txt/csv (np. za pomocą StreamWritter)
  będzie widać gdzie jest błąd dokładnie.
  Można oczywiście skorzystać po prostu z debugera jak pisał @ZrobieDobrze, ale te moje testy dadzą wynik bardziej "namacalny".

SqlCommand procedureCommand = new SqlCommand(procedureString, connection);
procedureCommand.CommandType = CommandType.StoredProcedure;

procedureCommand.Parameters.AddWithValue("@_deklarValue", data[54]); //do tego momentu dane są w formacie "1000000"

SqlDataAdapter adapter = new SqlDataAdapter(procedureCommand);
adapter.Fill(dt);

W tym fragmencie wskazywałem, że na debugerze zmienna jest typu string dlatego komentarzem opisałem jak wygląda zmienna wewnątrz tj: "1000000"

A typ kolumny w tabeli? Sprawdź profilerem jakie faktycznie zapytaie idzie do bazy i zweryfikuj czy jest poprawne.

AdamAdam_MF napisał(a):

... na bazie w kolumnie nvarchar (255) przyjmuje postać 1e+006

tak jak pisałem wcześniej kolumna jest typu nvarchar(255)

@Panczo: co masz na myśli pisząc profilem?

Miałem na myśli SQL Profiler. To odpowie na pytanie co faktycznie puszczasz na bazie.

https://support.microsoft.com/en-us/topic/how-to-use-sql-profiler-to-create-a-sql-trace-in-microsoft-sql-server-b8d41588-04b2-e121-f598-e0991cf0b6f1

Nie będzie wtedy wątpliwości gdzie jest przyczyna.