[sqlite] problem compiling loadable extensions using Visual Studio
I'm trying to find the way to develop loadable extensions using Visual Studio 2005. I've started by using the "half.c" extension from the documentation. I'm compiling using this command: cl /LD /I. /Fmhalf.map half.c The compilation proceeds without producing errors. I get a "half.dll", and the map file indicates that the "sqlite3_extension_init" is exported. But when I try to load the extension, I get this: SQLite version 3.5.9 Enter ".help" for instructions sqlite> .load 'half.dll' The specified procedure could not be found. sqlite> I've seen many descriptions in the archives that look to be similar to this, but I haven't found any that specifically named the Microsoft compiler in the problem statement. Anyone have the secret sauce for developing an extension using the Microsoft tools? Thanks, Doug ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
RE: [sqlite] PRAGMA table_info
This leaves you to parse the DDL from sqlite_master. Doug -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, April 13, 2006 2:51 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] PRAGMA table_info Marco Bambini <[EMAIL PROTECTED]> wrote: > Using PRAGMA table_info(...) there is no way to know if a column is > declared as unique and/or autoincrement. > Am I missing something? > Is there a way to get these info? > There is no pragma currently (that I recall) for finding if a column is unique or autoincrement. -- D. Richard Hipp <[EMAIL PROTECTED]>
RE: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2
I'd like to second Dennis' earlier remarks, and add some of my own. One of my greatest hopes when I found SQLite (it's "value proposition") was in having a great little database that would operate in such a familiar way. By "familiar", I mean that it should execute the SQL language, and produce (for the same DDL, and the same DML) the same result as other SQL implementations. In short, I expected it to comply with standards. Using standards is a two-way street: * I should be able to bring existing structures, and existing code from SQL Server, or Informix, or PostgreSQL, and have it not only run, but produce the same result. * I also want to use SQLite to create and test code that I may later take to one of these other platforms, and I'd like it to run the same there as it has been running in SQLite. The better it allows me to do both of the above, the more valuable it is to me. My friends and I joke that one of the greatest things about standards is that everyone gets to choose their own. I'd call SQLite's manifest typing one of "it's own". It is one of SQLite's greatest strengths, as well as it's greatest weakness. Being able to informally type a field is awesome, when I choose to use it. But it is a weakness when it influences a result unexpectedly (when it doesn't allow me to choose MY own standard). Most of my difficulty, and my greatest disappointments in using SQLite to-date has been where I got unexpected results when it did not strictly heed my formal DML instructions. My specific challenges have been with char(n)'s, but I think the learning applies equally to the discussion of real/int/numeric. Paradoxically, its greatest opportunity to grow and become more valuable to me is in allowing me the flexibility to call upon it to behave more strictly standard. By "strictly standard", I mean: * If I specify "INT", in my DML, I'd like it to behave exactly as an INT in other implementations. If it would like to abbreviate the value for compactness of storage, that's great. But I don't want it to store, nor return anything that behaves differently from an int. * Likewise FLOAT/REAL. I really don't care if SQLite stores it as a machine float, as an IEEE float, or as text. But if the field is a float, I don't want it to store, nor ever return anything that behaves differently from a float. * Likewise CHAR(n). It should not store, nor ever return any more than n characters. In situations where informal typing applies well, I'd like to be able to select this behavior explicitly. For example, by defining a column as VARIANT, or NUMERIC. If the "power" of manifest typing is its ability to recognize a value and properly convert it, and store it in a form as compact as it likes -- can that power be leveraged to retrieve a value, no matter how stored, and properly convert it back to behave exactly as the type it is expected to be, rather than as the type it was coerced to for storage? To sum it up: I place more value in how the fields behave than in how they're stored. I'd like more control, not less, in how they behave. Doug -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 01, 2005 10:55 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Proposed 3.3.0 changes. Was: 5/2==2 With the above clarification, I will restate the question: Suppose SQLite were to merge "integer" and "real" into a single datatype "numeric" that always worked the same way. Does anybody know of a (real) usage example where this would cause an actual hardship on developers? Are there any examples of things that you can do with separate "real" and "integer" types that you cannot do with a unified "numeric" type? -- D. Richard Hipp <[EMAIL PROTECTED]>
RE: [sqlite] Problem/Bug: "SELECT 5 / 2;" returns 2 ?
Perhaps not a solution, but a workaround: Try coercing the data entering the table into a value recognizable as a real: Create trigger t_t1i after insert on t1 Begin Update t1 set a = 1.0 * a, b = 1.0 * b Where rowid = new.rowid; End; Create trigger t_t1u after update on t1 Begin Update t1 set a = 1.0 * a, b = 1.0 * b Where rowid = new.rowid; End; The table will then hold reals in all cases. Expressions then work without change: Select a/b from t1; Update a set a = a / b; Doug -Original Message- From: Ralf Junker [mailto:[EMAIL PROTECTED] Sent: Monday, October 03, 2005 7:12 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] Problem/Bug: "SELECT 5 / 2;" returns 2 ? Hello DRH, >> 3. If the division of INTEGERs can not be stored as an INTEGER >>(i.e. if a % b != 0), the result should be returned as a REAL. >> > >create table t1( a integer, b integer); >insert into t1 values(5,2); >update t1 set a=a/b; > >If your rule above was in force, this would leave >T1.A holding 2.5, which is incompatible with the >way other database engines work. Well, understandable. But suppose that's exactly what one wants to do? How to achieve this using the current implementation of sqlite3? On the other hand, I think that the following, currently implemented behaviour of sqlite3 is also incompatible with the way other database engines work. Where they return 2.5 for real type columns, sqlite3 does not: create table t1 (a real, b real); insert into t1 values (5,2); select a / b from t1; 2 So the final question biols down to: How can I reliably guarantee a real type result for divisions on real typed columns even if they happen to contain integers? I cant't believe I always have to use a workaround like this: select 1.0 * a / b from t1; I am sure there must be a better possibility without the extra multiplication! Or is there not? Regards, Ralf
RE: [sqlite] NEW DATA TYPE IN SQLITE
Is the application written in the legacy language, or are you changing it, too? What language was/is it in? The TCL language library has the ability to link functions to the engine. Such functions can affect coercion of the data into a different type, so that storage and presentation of the data need not be the same. Combining the functions with triggers and views might do what you need. Choose function names wisely, and the SQL could still be portable. Doug -Original Message- From: John Stanton [mailto:[EMAIL PROTECTED] Sent: Friday, September 30, 2005 2:49 PM To: sqlite-users@sqlite.org Subject: [sqlite] NEW DATA TYPE IN SQLITE First a disclaimer. I am a new user of SQLITE and have not dug very deeply into the code and literature, so my question may be trivial. I have a system from an emulation of a legacy commercial language processor which uses a very handy fixed point decimal number system. The numbers are of arbitrary precision and held in right justified display format. As you can imagine arithmetic on such numbers is not blindingly fast but for general commercial usage they are truly excellent. Commercial applications are not calculation intensive but are display intensive so the time saved in radix transformation and editing far exceeds the time lost in divisions. This type of fixed point display format number with automatic rounding makes it very easy to produce reports which balance to the penny and incredibly easy to generate financial reports. Such a number type does seem to fit in with the SQLITE concept of loose typing, since it is actually just a text field. There is actually an obscure ANSI standard which defines these numbers. How feasible and how difficult would it be to add this type to SQLITE? The numbers store as text strings so what is involved is adding the new numeric type and inserting the arithmetic functions so that they are recognized by the SQL processor? If anyone has a quick answer I should appreciate it. PS, with such fixed point numbers you would have 5.0 / 2.0 = 2.5 exactly.
