Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM SQL » View Thread |
Messages 1 to 5 of 5 total |
Error 4.25 B 4 |
Wed, May 30 2007 9:22 AM | Permanent Link |
"Robert" | Using an extension for memory tables causes parsing errors.
select * into memory\temp from custtable; works select * into memory\temp.dat from custtable; does not. Robert |
Wed, May 30 2007 1:02 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Robert,
<< Using an extension for memory tables causes parsing errors. select * into memory\temp from custtable; works select * into memory\temp.dat from custtable; does not. >> Using the backslash as a database name separator without double-quotes is only permitted because Crystal Reports requires it. You should always enclose any table specifier with backslashes or file extension separators in double quotes: select * into "memory\temp.dat from custtable"; http://www.elevatesoft.com/dbisam4d7_naming_conventions.htm -- Tim Young Elevate Software www.elevatesoft.com |
Wed, May 30 2007 1:38 PM | Permanent Link |
"Robert" | "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message news:C44D8510-3A34-474D-B745-6AC3AF6F758F@news.elevatesoft.com... > Robert, > > << Using an extension for memory tables causes parsing errors. > > select * into memory\temp from custtable; > > works > > select * into memory\temp.dat from custtable; > > does not. >> > > Using the backslash as a database name separator without double-quotes is > only permitted because Crystal Reports requires it. You should always > enclose any table specifier with backslashes or file extension separators > in double quotes: > It would be nice if changes in SQL syntax were announced loudly and way in advance. As you can imagine, I don't know how many of those are lurking in my numerous DBISAM applications. It was legal until recent versions. > select * into "memory\temp.dat from custtable"; > The above does not work. Robert |
Thu, May 31 2007 7:56 AM | Permanent Link |
Chris Erdal | "Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote in news:D68DB417-
1EFB-4796-8DA3-ACA383BC9B9E@news.elevatesoft.com: >> select * into "memory\temp.dat from custtable"; >> > > The above does not work. > Looks like a typo - should probably have been: select * into "memory\temp.dat" from custtable; -- Chris (XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 4 + EDB 1.03 build 1) |
Thu, May 31 2007 3:18 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Robert,
<< It would be nice if changes in SQL syntax were announced loudly and way in advance. As you can imagine, I don't know how many of those are lurking in my numerous DBISAM applications. It was legal until recent versions. >> It has never been legal in DBISAM to use a file extension separator without enclosing the file name in double-quotes or brackets. This is from the DBISAM version 1 help file: ======================================== DBISAM's SQL supports full file and path specifications in table references. Table references with path or filename extensions must be enclosed in single or double quotation marks. For example: SELECT * FROM 'parts.dat' SELECT * FROM "c:\sample\parts.dat" ======================================== And, again, the only reason for the exception for the backslash is to get DBISAM to eat the botched up SQL that CR sends it with catalog name backslashes that aren't double-quoted. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Sunday, May 5, 2024 at 10:18 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |